Constructors (was: RE: About KCP and automatic initialize)

Daniel Vainsencher danielv at netvision.net.il
Fri Sep 19 09:36:03 UTC 2003


"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> I think we need to remind ourselves what Squeak is, here.
> Squeak is an *open* system, where everything that the IDE needs is
> accessible to a program.
> So derived methods are *already* possible.
Sure. Methods can be written. But the user doesn't expect them to be,
and generally, they aren't. So the assumption generally works, aside
from statistically insignificant hack like the accessors
auto-generation.

> So the "assumptions in that simplicity" are unfounded; Squeak is a little
> bit pregnant.  You can't abort that pregnancy without killing off the tools
> or the openness.  Better to bring it to birth.
> 
> 	1.  A class-side DNU which looks up the message on the instance
> 	side, and if an implementation is found in the initialize
> 	protocol, creates a method that calls it.
> 
> Ooh, nice one!  The same effect as Andreas Raab's proposal, but without
> any syntax change at all.  BUT, it's making a derived method.

And from Andreas' perspective -
> That's about the worst solution I can imagine. It would mean that whenever I
> have a mistake in spelling a method I get a new initializer on the class
> side. 
I forgot to mention that I'd have it bring up a dialog to ask the user
before doing that. The point is to help the user create code, not to
have them pop up uninvited methods. These are not derived methods
exactly because the user creates them, and there after semantics are the
usual Smalltalk ones.
 
> 	2.  A menu option for methods "make initializer" that generates
> 	the stub described above on the class side.
> 
> Again, this is making a derived method.  Either the system is revised to
> keep track of the derivation, so that it can be repeated when the base
> method is revised, or the two methods can get out of synchrony (add an
> argument to the instance-side method and the class-side method doesn't
> get to hear about it). 
I'd go for the second, and not do anything in particular to keep them in
synch. People that care about correctness when refactoring would be
using the RB to do such work anyway, and I like that division of
responsibilities.

> In some ways I like option 2 the best, but it has a disadvantage:
> when a human is looking at the instance-side method, s/he can't tell
> that it's an initializer.  Perhaps if the menu option were only available
> for methods in an 'instance creation' category, ah, I'm onto something here.
[snip]
This seems like a good direction to follow for me. If we find the tool
change is enough to scaffold the users through creating their classes,
maybe the language changes can be focused on more important issues, like
the auto-mangled macro selectors that are being discussed elsewhere on
this thread.

Daniel



More information about the Squeak-dev mailing list