Singelton method

Hi,
    In Ruby, singleton method is a default capability, which it is proud of
among other competent scripting object-oriented language such as Perl,
Python, and it is said that it is available only in a few other languages,
such as Self etc. You can just create instance's method easily with:
     a = someClass()
     def a.someMethod
           code snippet....
     end
  I personally felt it is very convenient to have it, as it is said that it
is quite frequently used in GUI, e.g. each button instance had its own
singleton method.
    In Smalltalk, specifically Dolphin Smalltalk, is the same kind of design
pattern of singleton method available? ( if I'm not wrong, it's just like
that every class is made by MetaClass and owned its own singleton methods)
or there are already some workarounds of implementation ( method wrapper or
other else) that do the same things?

Best regards.
kuo

kuo

You wrote in message news:[hidden email]...
>
>     In Ruby, singleton method is a default capability, which it is proud
of
> among other competent scripting object-oriented language such as Perl,
> Python, and it is said that it is available only in a few other languages,
> such as Self etc. You can just create instance's method easily with:
>      a = someClass()
>      def a.someMethod
>            code snippet....
>      end
>   I personally felt it is very convenient to have it, as it is said that
it
> is quite frequently used in GUI, e.g. each button instance had its own
> singleton method.
>     In Smalltalk, specifically Dolphin Smalltalk, is the same kind of
design
> pattern of singleton method available? ( if I'm not wrong, it's just like
> that every class is made by MetaClass and owned its own singleton methods)
> or there are already some workarounds of implementation ( method wrapper
or
> other else) that do the same things?

Certainly you can do this:

http://groups.google.com/groups?selm=abqg81%24khmi1%241%40ID-51044.news.dfncis.de

Hope this helps

Blair

Kuo,

Blair wrote:
>
> >     In Smalltalk, specifically Dolphin Smalltalk, is the same kind
> > of design pattern of singleton method available?
> [...]
> Certainly you can do this:
>
>
http://groups.google.com/groups?selm=abqg81%24khmi1%241%40ID-51044.news.dfncis.
de

It's worth adding, though, that although the technique is perfectly proper, it
isn't the *idiomatic* way to write Smalltalk.  That may, or may not, matter to
you.

For instance, a more typical way handling your example (adding the action code
to a button) would be to have the button own a Block which it evaluated when it
was pressed.   (That isn't how Dolphin's buttons do work, BTW.)

    -- chris

Thanks for your instructions.
   In JNIPort, it seemed also used the technique of metaclass-class pair in
designing the Ghost Classes for building dynamic wrapper class to interface
Java objects, which they are called the Proxies ( as instances of subclasses
of JavaStatic).
   There a lot more treasure in it that worthy spending time and I found I
could learn much good practice pattern from it eventually, thanks.

   BTW, you had mentioned the JVMs. There is currently only one JVM, but it
is said that the platform could be expanded to support much more VMs if
available , which hopefully could be selected and activated at will in the
future.
     Therefore, I wondered that Python is also a good target, since there is
Jython. Could similar port theorectially be done to interface Python class
objects or functions in their modules with the same framework. Python also
had a lot of good modules everywhere, some even already rewritten in C,
optimized and compiled for efficiency, that deserved to make use of, if we
could have the interfaces as convenient as JVM afforded.


Best regards.
kuo


"Chris Uppal" <[hidden email]> wroten in
news:3ed5db8d$0$45183$[hidden email]  :

>
> It's worth adding, though, that although the technique is perfectly
proper, it
> isn't the *idiomatic* way to write Smalltalk.  That may, or may not,
matter to
> you.
>
> For instance, a more typical way handling your example (adding the action
code
> to a button) would be to have the button own a Block which it evaluated
when it
> was pressed.   (That isn't how Dolphin's buttons do work, BTW.)
>
>     -- chris
>
>

kuo wrote:

>    In JNIPort, it seemed also used the technique of metaclass-class
> pair in designing the Ghost Classes for building dynamic wrapper
> class to interface Java objects, which they are called the Proxies (
> as instances of subclasses of JavaStatic).

Yes, JNIPort does use dynamic classes a lot.  (But not to obtain
instance-specific behaviour)

>    There a lot more treasure in it that worthy spending time and I
> found I could learn much good practice pattern from it eventually,
> thanks.

\(^o^)/  If you found something of value there then I'm very pleased.  Thank
*you*.

I'd expect the same sort of techniques could be used to create interfaces to
any language that had objects, classes, introspection, and a decently
well-designed 'C' interface.  I haven't looked at how to link to Python's
execution engine, but my guess is that it would be quite feasible -- I doubt if
I'll try to do it myself, though, (JNIPort came out of a specific need of mine
to interface to Java, I don't have a comparable need to talk to Python).  I
don't think the existing framework could be used *directly* (it wasn't designed
for anything except Java) but I think it could be adapted to other languages
with some effort.

By the way, if you just want to talk to Jython from Dolphin, then you can use
JNIPort as it is.  That won't generate wrapper classes for each Python class,
but you can use the normal jython java methods for talking to Python objects
just as you would if you were embedding jython in a Java program.

There is a bug in jython where several jython object classes assume that the
class itself will not be loaded until after the jython system has been
initalised.  This causes problems for JNIPort because it loads classes in a
different order.  You can get around the problem by defining a helper Java
class something like:

=============
package org.whatever;

public class JythonForJNIPort
{
        public static Object
        make()
        {
                return new org.python.util.PythonInterpreter();
        }
}
=============

and then calling org.whatever.JythonForJNIPort.make() from JNIPort, instead of
creating a PythonInterpreter  instance directly.  That will ensure that the
jython classes are initialised in the order that they expect *before* JNIPort
tries to load any of them.

    -- chris