Des (deskitty) wrote,
Des
deskitty

  • Mood:
  • Music:

Dryice Update

Damn, I am tired. Today was probably my most productive day so far this summer with Dryice.

>>> Progress Today

Most of the storage framework is now written, which means there will soon be an easy way to save and restore Dryice objects (including the bytecode which is generated by the compiler).

I also did a fair bit of work with the webpage, so there's a bit more information there now, including an outline/roadmap and a list of features I want the language to have.

>>> Musings about Object and Functional Models

So Dryice is (or will be) a weird mix of functional and object-oriented models. Functional models are good, especially in threaded programming, because they tend to assume most data structures are immutable. Immutable data structures are less complex code-wise and don't need locking (locking requires a lot of overhead). So Dryice's data structures will be as immutable as they can be, and I'll only allow changes (and do locking) where I really need to.

But I also like the object-oriented paradigm. My experience writing software so far has shown me that it's an incredibly powerful way to do things, and I don't think any modern language is complete without it. Hell, I'll admit it, OOP is central to my way of thinking about programs. ;)

The problem is, to be really useful, objects need to be mutable. (This certainly isn't true for all objects, but it is true for a non-trivial subset.) This is fine if you have proper locking in place for those that need it, but there is a danger that objects (I am speaking here of Dryice objects, not native C++ objects) may be touched by multiple threads before they are fully constructed. I don't think I need to explain why this is bad.

So my current dilemma is this: if Dryice constructors can execute arbitrary (byte)code (including spawning/touching other threads), how do I prevent other threads from getting hold of an object before it gets to a consistent state?

My intuition suggests there is only one solution to this problem ... collect all the object's data members (by calling its various constructors), and wait to create the object itself until the very last moment. But I guess we'll see how the details shake out in implementation.

-- Des

 22:41:22 up 1 day, 21:24,  3 users,  load average: 0.24, 0.06, 0.02
Subscribe

  • (no subject)

    Well, I'm off to Dreamwidth. I hope to see you all there! Nice knowing you, LJ. It's been grand. — Des

  • A fresh start?

    So I'm thinking of moving away from LJ. Every time I glance at my ad blocker, there are an uncomfortably-large number of advertising and tracking…

  • 2012: Ramp It Up

    It’s that time of the year again -- another year has passed, and as usual, I don’t finish reflecting on it until the first 3 months of the following…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments