Thanks for your reply, David,

I must note that I'm not sure if my argument is correct. It is just an argument.

Interestingly the closest thing I've seen to Self in terms of prototype
inheritance & instance specific  methods is the ubiquitous JavaScript. In
JavaScript the only way to associate methods to classes is to assign them to a
prototype at runtime.  But I'm not sure if I'd be happy using it for a medium
sized application.

I know that SmallScript is explicitly meant to be a 'scripting language'.
Scripting languages typical use is to 'glue' together more basic functionality.
In such a case more flexibility the language offers the better.

There's value in being able to understand exactly the initial state of the
system before the program starts running,  and only after that have  to go on
reasoning how it changes due to procedural semantics. Such 'invariants' of the
program allow us to understand it more easily, produce it more quickly, and
avoid errors more efficiently. Such is the rationale also behind preconditions,
postconditions and class invariants in Eiffel and other languages.

_Panu


David Simmons wrote:

> Panu,
>
> I think you are making some broad assertions that might hold true in a
> classic Smalltalk System using Smalltalk tools, Smalltalk practices, and a
> class based MOP implementation model.
>
> However, as a counterpoint to Smalltalk idioms, I believe that prototype
> languages like the "self" language system do not suffer from the problems
> you assert. A point which should be distinguished from whether it may be the
> case that they would suffer from such issues if classic Smalltalk tools and
> techniques were used to implement them and author in them.
>
> It is also not clear that the concerns/points you raise are issues for
> typical/current usage patterns in languages like Ruby, Python, etc [which is
> the usage context from which the original question was drawn].
>
> I.e., The original poster was, by implication, asking if Smalltalk was
> capable of supporting their Python mechanisms and style of development.
>
> >> In Python, the following actions are legal and very easy to accomplish:
> >>
> >>- persist almost anything
> >>- add new members to objects at runtime
> >>- add new methods to objects at runtime
> >>- methods can return methods
> >>
> >>I'd like to know whether these can be done in Smalltalk.
>
> ---
>
> I've forwarded this post to David Ungar [the principal author of "self"],
> who is almost certainly in a much better position than I am to make cogent
> comments regarding your assertions. [this thread was posted to:
> comp.lang.smalltalk, comp.lang.smallscript.advocacy,
> comp.lang.smalltalk.advocacy, comp.software.patterns,comp.lang.ruby].
>
> -- Dave S. [www.smallscript.org]
>
> "Panu Viljamaa" <panu / fcc.net> wrote in message
> news:3BE3C776.C0C38A14 / fcc.net...
> > David Simmons wrote:
> >
> > > ...
> > > In classic Smalltalk, you may dynamically add/remove methods and members
> > > from a formal "class" of objects but not an individual object [or an
> > > ad-hoc/proto group of objects].
> >
> > A. Instance Specific Methods (ISM)
> > ==================================
> > Even in classic Smalltalk you can create a class whose instances accept
> new
> > methods at runtime. The exact code to create such a class has been
> presented in
> > the Smalltalk Report for instance.
> >
> > I experimented with this coding style years ago, and found it made the
> code hard
> > to understand and maintain. If you need to 'configure' the behavior of an
> object
> > at runtime, I suggest using Blocks for this purpose. This makes your code
> better
> > reflect this design decision, by having explicit setter methods for
> installing
> > the behavior modifying blocks for instance.
> >
> >
> > B. Instance Specific Variables  (ISV)
> > =====================================
> > Regarding the addition of instance variables at runtime, the idiom is to
> have a
> > Dictionary hold on to the 'ad hoc' attributes of an object (including
> executable
> > blocks if [A.] is desired). As with instance specific methods, the code
> would
> > become confusing and hard to maintain if the class declaration states a
> set of
> > instance variables, but in fact at execution time more are stealthily
> added.
> >
> > In summary: If you expect the instances of a class to be dynamically
> modifiable
> > either in behavior or structure, it is best to reflect this decision
> already in
> > the static definition of the class. You don't need these features always.
> But it
> > makes it easier to understand the program when you know where such 'non
> > conformant' behavior is potentially in effect and where not.
> >
> > ISM and ISV might seem to add power to a language, but this power is
> destructive
> > when used in an uncontrolled fashion.
> >
> > -Panu Viljamaa
> >
> >
> >