The Road to CoreObject Part 1: EtoileSerialise
Linked by Thom Holwerda on Sun 22nd Jul 2007 15:25 UTC
OpenStep, GNUstep CoreObject is intended to be one of the foundation pieces of Etoile. The current roadmap calls for an experimental version in 0.3, a stable interface in 0.4, and a completely stable version in 0.5. "What is CoreObject? Basically, it's a replacement for a filesystem as a programmer and user interface. Files (in the UNIX sense of the word) never were a good abstraction; an untyped series of bytes is no use to anyone. The operating system needs to deal with things like this, but programmers shouldn't have to. We already have a much nicer abstraction than a file; the object. Unlike files, objects have all of the structure and introspection that we want in order to be able to interact with them programatically. In EtoilE, we want to treat everything as an object, and objects as first-class citizens."
E-mail Print r 0   14 Comment(s) http://osne.ws/e4j
Thread beginning with comment 257278
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: files vs object?
by NicolasRoard on Sun 22nd Jul 2007 19:11 UTC in reply to "files vs object?"
NicolasRoard
Member since:
2005-07-16

i could have sworn that files are a kind of object, so where does this "hate" for files come from?

It's not hate per se, it's just that files are not a particularly great abstraction compared to object serialization (mind you, automatic object serialization has its own problem too, but it's anyway definitely a step up from the unorganized binary blob that is a file).

In any way, CoreObject is cool because it does most of the work for you, and we are lazy. Beside, using CoreObject as a middleware you could imagine changing the way objects are actually saved/loaded without the app knowing it (that's what EOF more or less did);

Using a common way of storing structured information also opens lots of interesting way for collaboration among apps (e.g. a la NewtonOS).

I stopped reading after "Objective-C".

It's so... passè.

Idiot.

Edited 2007-07-22 19:12

Reply Parent Score: 5

RE[2]: files vs object?
by hobgoblin on Sun 22nd Jul 2007 20:12 in reply to "RE: files vs object?"
hobgoblin Member since:
2005-07-06

sounds like i need to read up on some theory...

Reply Parent Score: 2

RE[2]: files vs object?
by rayiner on Mon 23rd Jul 2007 00:18 in reply to "RE: files vs object?"
rayiner Member since:
2005-07-06

I disagree on the file issue. Files are a perfectly good abstraction for what they are --- a low-level OS mechanism. I don't think object-serialization is a particularly appropriate abstraction for that sort of thing. The real problem is that for far too long, its been really the only abstraction available. At the application level, you really want to use something higher-level.

As for the "idiot" bit, I agree. One day, people will realize the genius of Alan Kay, but until then, this is the sort of thing we have to put up with...

Reply Parent Score: 3

RE[3]: files vs object?
by renox on Mon 23rd Jul 2007 05:37 in reply to "RE[2]: files vs object?"
renox Member since:
2005-07-06

>>One day, people will realize the genius of Alan Kay, but until then, this is the sort of thing we have to put up with...<<

Well, one could say that Ruby is Smalltalk with a more C-like/Perlish syntax to avoid the 'syntax shock' for people which are used to other languages..

My own pet peeve with Smalltalk beside the syntax is the variable declaration separated from the initialisation: the 'nil-state' which is triggered by this is quite ugly.. Strange, that they don't have fixed it yet.

Reply Parent Score: 2