Dylan - Relective operation of classes, how to get names

Author

Relective operation of classes, how to get names

Michael Erdmann

2004-12-01, 8:56 pm

Dear all,

is there any reflective operation on classes available which
provides a list of slots? I have check the DRM but i cant find
such a thing in chapter 12.

Regards
M.Erdmann

Hugh Greene

2004-12-01, 8:56 pm

On Wednesday 01 Dec 2004 20:19, Michael Erdmann wrote:
> Dear all,
>
> is there any reflective operation on classes available which
> provides a list of slots? I have check the DRM but i cant find
> such a thing in chapter 12.
>
> Regards
> M.Erdmann

There's intentionally no standard way to do that in Dylan, presumably
because it allows for more optimisation and smaller binaries. (It also
means you maybe have somewhat less need to "obfuscate" shipped apps as with
the JVM/.NET -- it's more like C/C++ in that respect.)

Having said that, I think both FunDev and Gwydion provide some
implementation-specific ways to get at a bit more reflective information
that the DRM supplies -- more knowledgeable folks will have to provide the
details.

A standard approach to this, if you're creating classes for a specific
purpose where you need more reflection information, can be to write a macro
wrapping \class-definer and use it to capture the names of the slots etc.
as strings/symbols. For example, the following (untested) just captures
the slot names; capturing other information would be more complicated.

----------------------------------------------------------------
define constant $class-slots-lookup :: <table> = make(<table> );

// extra reflection => shiny :-)
define macro \shiny-class-definer
{ define ?mods:* shiny-class ?:name (?supers:*) ?slots:* end }
=> { define ?mods class ?:name (?supers) ?slots end;
record-class-slots(?name, ?slots); }
end macro;

define macro record-class-slots

{ record-class-slots(?:name, ?slots) }
=> { $class-slots-lookup[?#"name"] := vector(?slots); }

slots:
{ ?slot ; ... }
=> { ?slot , ... }

slot:
{ ?mods:* slot ?:name ?rest:* }
=> { ?name }

{ ?other:* }
=> { }

end macro;
----------------------------------------------------------------

Hope that helps,
Hugh.

--
Remove ".NO" and "SPAM." to reply.

Michael Erdmann

2004-12-04, 8:55 am

Hugh Greene wrote:
> On Wednesday 01 Dec 2004 20:19, Michael Erdmann wrote:
>
Thanks this was helpfull. To give some background on what i am
trying to do. I have used in the past very often the framerd
data base. I am currently trying to integrate FramerD with the
gw dylan implementation in order to evaluate dylan. I have done
the same thing with scheme (namly chicken scheme compiler)
last month, but i can't get used to scheme.

In order to integrate framerd and dylan i have to setup some
kind of seamless persistency conmcept. The DRM seems not
to have such issues in it's scope. Are there attempts in the
dylan community for object persistency?

Michael

>
>
> There's intentionally no standard way to do that in Dylan, presumably
> because it allows for more optimisation and smaller binaries. (It also
> means you maybe have somewhat less need to "obfuscate" shipped apps as with
> the JVM/.NET -- it's more like C/C++ in that respect.)
>
> Having said that, I think both FunDev and Gwydion provide some
> implementation-specific ways to get at a bit more reflective information
> that the DRM supplies -- more knowledgeable folks will have to provide the
> details.
>
> A standard approach to this, if you're creating classes for a specific
> purpose where you need more reflection information, can be to write a macro
> wrapping \class-definer and use it to capture the names of the slots etc.
> as strings/symbols. For example, the following (untested) just captures
> the slot names; capturing other information would be more complicated.
>
> ----------------------------------------------------------------
> define constant $class-slots-lookup :: <table> = make(<table> );
>
> // extra reflection => shiny :-)
> define macro \shiny-class-definer
> { define ?mods:* shiny-class ?:name (?supers:*) ?slots:* end }
> => { define ?mods class ?:name (?supers) ?slots end;
> record-class-slots(?name, ?slots); }
> end macro;
>
> define macro record-class-slots
>
> { record-class-slots(?:name, ?slots) }
> => { $class-slots-lookup[?#"name"] := vector(?slots); }
>
> slots:
> { ?slot ; ... }
> => { ?slot , ... }
>
> slot:
> { ?mods:* slot ?:name ?rest:* }
> => { ?name }
>
> { ?other:* }
> => { }
>
> end macro;
> ----------------------------------------------------------------
>
> Hope that helps,
> Hugh.
>

Peter Robisch

2004-12-07, 4:07 am

"Michael Erdmann" <michael.erdmann@snafu.de> wrote in message
news:67l882-ok3.ln1@boavista.mydomain.de

> Are there attempts in the
> dylan community for object persistency?

Fun-O offers a Persistent Storage Library Pack (1625K, $24.95).
I expect you can find it also in one of OpenDylan subversion
directories.
So far I know it only defines the interface level not containing
an implementation.
If you need further information I can try to search the module
names. Tomorrow. Currently I have to switch to another task.

Peter

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Sponsored Links