About KCP and automatic initialize

ducasse ducasse at iam.unibe.ch
Mon Sep 15 18:31:51 UTC 2003


hi ned


On Lundi, sep 15, 2003, at 18:41 Europe/Zurich, Ned Konz wrote:

> On Sunday 14 September 2003 11:40 pm, ducasse wrote:
>> Richard what you want is defensive and good components. I agree
>> with those goals. What we want is
>> to have a ***DEFAULT*** and simple instance initialization
>> mechanism.
>
> But the underlying assumption -- that there is in fact something
> sensible you can do for default initialization across *all* classes
> -- is what Richard (and I) disagree with.

I do not understand why simply having a better default initialization 
schema that
let everybody breaks the rule the way he wants is a problem.

> Some objects do not necessarily make any sense outside of their
> community of cooperating objects, or outside the time during which
> they're needed. Trying to force all objects into a pattern that is
> easily taught doesn't necessarily make for code that is efficient, or
> easily maintained or understood.

Come on. We are trying to force anything. Do not tell me that you never 
do X new to get an object
well initialized. This automatic initialize is one call the benchmarks 
show that this is nearly free.

> One example is abstract classes: what sense does it make to have
> default initializers if a class is abstract?

So what is the problem then.

> Remember too that object state doesn't necessarily come from instance
> variables. A good example is a Socket or StandardFileStream (or an
> I/O point in an embedded system, etc.). These objects have little
> useful intrinsic state, and there is no sensible return value from
> #new for them that will not require testing *throughout the rest of
> the object's code* to see whether the object is in fact in a sane
> state. Which we do in many cases to deal with restarting the image,
> but it's been a recurring source of bugs.
>
> Would you suggest that (for instance) a Stream should have a default
> constructor? Streams only exist to stream over collections, and it
> makes little sense to create one without having a collection in hand.

I'm not saying that this default constructor is universal. Why don't 
you read what we say?


> There are even Morphs that aren't usable by themselves: AtomMorph,
> GeeBookPageMorph, and others don't really make any sense outside
> their normal usage.
>
> This list also includes most proxies, adaptors, bridges, etc., as well
> as objects that exist solely to represent relationships between other
> objects.
>
> I would object to default constructors that set an instance variable
> only to reset it immediately thereafter in the course of normal
> usage.
>
> And I question whether the additional code required to make objects
> useful once instantiated by a default constructor is worth it
> overall.

Why wouldn't it be? You remove a lot of duplicated idiot code. You 
ensure that
for simple object you have a place to initialize them.

> Perhaps it would make sense (as has been suggested earlier) to have
> new learners subclass some class other than Object at first. You
> could easily add a PedanticObject that behaved exactly according to
> easily-taught rules (and perhaps also added some support code for
> easy inspection or interaction) and then later teach the more
> powerful general concepts.

I do not really understand why you use Pedantic but this is not my 
problem.
You are free to think that this point is pedantic. Note that you have 
also to have also a suclass for Model

I think that this is really a hack. Do you think that we would lose our 
time for that point.

Then you should explain to me why in the CLOS MOP make-instance calls
allocate and initialize? may be they were pedantic or may be they 
designed it conciously.
May be the creation of instance is really allocation followed by 
initialization.

stef

>
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>



More information about the Squeak-dev mailing list