[Gd-hackers] koala changes
Peter Robisch
peter.robisch at gmx.net
Mon Jan 22 12:21:33 CET 2007
> carl wrote:
> Hmm. I don't see how a macro will help.
> ...
Maybe I did not graps your issue well.
So let me phrase your issuse with my words and
explain my idea in other words.
My understanding of your issue is
(1) You face these requirements
- store the slots values
- and retrieve the stored values
(2) You like to make transparent in the code where you use
- just a non-configurable core server
- or a configurated one
You current approach uses the same slot name for the
server and config object.
IMHO -- or should I say my Dylan feeling tells me, but I can explain it--:
(1) a macro only lists slot name
(That's my feeling when I look on the DUIM define frame macro).
(2) To whom these slots belong are parameterized to the macro.
(That's my feeling when I see the clapsed frame in definiton line
define frame (frame)
)
Here a proposal
(1) use these classes:
<server> describing the non-configurable core server
<configurable-server> abstract class
hold the code to persistent the server data
<http-server> a server configuration type
// to define a configuration
// just to generalize the idea of configurations
// Somewhere in the background the parameter server and http
// to check that the given slot name are acceptable.
define configuration (server, http)
end define
let http-server-config = make (<configuration>)
// to configure a server
// <http-server> is a direct(?) of <configurable-server>
let http-server =
make(<server>, configuration: http-server-config )
define generic method
persistent-configuration
( <configurable-object>, <locator> => <boolean> )
end method
// if necessary
define method
persistent-configuration
(<configurable-server>, <locator> => <boolean> )
end method
let http-server =
make(<server>, configuration-locator: http-server-config-locator )
Any further comments required?
Pet-ro
More information about the hackers
mailing list