Question: How to do it in Smalltalk 
Author Message
 Question: How to do it in Smalltalk


Quote:

> I'm trying to find the right tool that enables me to try new ideas.
> So far, python seems to be the most flexible.

> 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

Yes to all.

But, there is a proviso on adding methods and members to [some ad-hoc set
of] objects.

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

Thus if you have a "array" object and you want to add a new variable to that
particular object you cannot do so in classic smalltalk. Similarly you
cannot add a method to just that object. You can add a method to the <Array>
class and thus make the behavior/method available to all instances of
<Array>.

Some Smalltalk dialects allow you to add per/instance (per/object) behavior
and variables/fields/members to objects. This style of language is known as
a prototype language and is best epitomized in the "self" language by David
Ungar, et al. Classic Smalltalk is a "class" based language (no pun
intended).

The work I've done in developing the SmallScript language (an extended
superset of Smalltalk) does provide the ability to do all the above
features.

  I.e.,
  a) Modify a class of objects
  b) Modify an individual object (or some grouped proto-set)

-- Dave S. [www.smallscript.org]

Quote:

> I'd like to know whether these can be done in Smalltalk.

> Thanks for any help.

> Cheers,

> Kroly

____________________________________________________________________________
__
Quote:
> Posted Via Binaries.net = SPEED+RETENTION+COMPLETION =

http://www.*-*-*.com/


Wed, 21 Apr 2004 08:47:26 GMT  
 Question: How to do it in Smalltalk

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



Wed, 21 Apr 2004 18:31:19 GMT  
 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  
 
 [ 4 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