(Re: Question: How to do it in Smalltalk) 
Author Message
 (Re: Question: How to do it in Smalltalk)

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.

Quote:
>> 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]


Quote:

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



Thu, 22 Apr 2004 05:37:09 GMT  
 (Re: Question: How to do it in Smalltalk)
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

Quote:

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




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



Fri, 23 Apr 2004 02:40:44 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. How is Smalltalk doing these days?

2. Anyone done OPC with any of the Smalltalks?

3. doing a paper on smalltalk

4. Doing assembly and really doing assembly

5. Doing assembly and really doing assembly

6. who is doing smalltalk/sql development?

7. Anyone done Sun RPC/XDR in Smalltalk?

8. Stupid newb question: What am I doing wrong?

9. Newbie Question - Usual ways of doing th

10. Newbie Question - Usual ways of doing things.

11. Newbee Template question - Can this be done?

12. what am i doing wrong? HLA question

 

 
Powered by phpBB® Forum Software