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
>
>
>