Greetings,
I need your advise on a "good" way to save information on class
definition.
What I want is a way to get all the initargs of a given class, but I
can't figure how to do that on a portable way with the MOP.
Here is a solution I got , but please let me know what do you think of
it (especially if it exists a better way to get that)
------------------------
(defparameter class-initargs (make-hash-table))
(defun get-class-initargs (class-symbol-name)
(getf (gethash class-symbol-name class-initargs) :initargs))
(defun get-precedence-class-initargs (classes)
(apply #'append (mapcar #'get-class-initargs classes)))
(defun get-slots-initargs (prec-classes slots)
(loop with prec-initargs = (get-precedence-class-initargs
prec-classes)
for slot in slots
for initarg = (getf (cdr slot) :initarg)
when initarg collect initarg into initargs
finally (return (nconc initargs prec-initargs))))
(defmacro define-class (name (&rest prec-classes) (&rest slots))
`(progn
(setf (gethash ',name class-initargs)
'(:initargs ,(get-slots-initargs prec-classes slots)))
(defclass ,name ,(if prec-classes prec-classes `())
,slots)))
Iban HATCHONDO <········@yahoo.fr> writes:
> Greetings,
> I need your advise on a "good" way to save information on class
> definition.
> What I want is a way to get all the initargs of a given class, but I
> can't figure how to do that on a portable way with the MOP.
Hmmm, doesn't SLOT-DEFINITION-INITARGS together with CLASS-SLOTS do
what you want? I.e.
(defun get-valid-class-initargs (class)
(loop for slot in (class-slots class)
appending (slot-definition-initargs slot)))
should do what you seem to be wanting to do (note that since
class-slots returns the effective-slot-definition objects, and hence
takes care of all inheritance issues already.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" wrote:
> Hmmm, doesn't SLOT-DEFINITION-INITARGS together with CLASS-SLOTS do
> what you want? I.e.
>
> (defun get-valid-class-initargs (class)
> (loop for slot in (class-slots class)
> appending (slot-definition-initargs slot)))
>
> should do what you seem to be wanting to do (note that since
> class-slots returns the effective-slot-definition objects, and hence
> takes care of all inheritance issues already.
>
> Regs, Pierre.
You and Paul Foley give me the same answer and I agree, but
I have to say that I was knowing the existance of that method, but the
question that came to my mind was : will this work with "all" CL
implementation !!?? (it does with cmucl - when using the pcl package - ).
Any advise ?
Iban HATCHONDO <········@yahoo.fr> writes:
> "Pierre R. Mai" wrote:
>
> > Hmmm, doesn't SLOT-DEFINITION-INITARGS together with CLASS-SLOTS do
> > what you want? I.e.
> >
> > (defun get-valid-class-initargs (class)
> > (loop for slot in (class-slots class)
> > appending (slot-definition-initargs slot)))
> >
> > should do what you seem to be wanting to do (note that since
> > class-slots returns the effective-slot-definition objects, and hence
> > takes care of all inheritance issues already.
> >
> > Regs, Pierre.
>
> You and Paul Foley give me the same answer and I agree, but
> I have to say that I was knowing the existance of that method, but the
> question that came to my mind was : will this work with "all" CL
> implementation !!?? (it does with cmucl - when using the pcl package - ).
> Any advise ?
At the cost of sounding extremely conservative and backward thinking,
I would advise you to avoid MOP programming if you want to keep yopur
programs portable.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Iban HATCHONDO <········@yahoo.fr> writes:
>
> > "Pierre R. Mai" wrote:
> >
> > > Hmmm, doesn't SLOT-DEFINITION-INITARGS together with CLASS-SLOTS do
> > > what you want? I.e.
> > >
> > > (defun get-valid-class-initargs (class)
> > > (loop for slot in (class-slots class)
> > > appending (slot-definition-initargs slot)))
> > >
> > > should do what you seem to be wanting to do (note that since
> > > class-slots returns the effective-slot-definition objects, and hence
> > > takes care of all inheritance issues already.
> > >
> > > Regs, Pierre.
> >
> > You and Paul Foley give me the same answer and I agree, but
> > I have to say that I was knowing the existance of that method, but the
> > question that came to my mind was : will this work with "all" CL
> > implementation !!?? (it does with cmucl - when using the pcl package - ).
> > Any advise ?
>
> At the cost of sounding extremely conservative and backward thinking,
> I would advise you to avoid MOP programming if you want to keep yopur
> programs portable.
Whereas I would like to encourage you to use the MOP and to file bug
reports on those implementations that don't implement it, if the fact
that it doesn't run on that implementation bothers you.
The MOP as described in AMOP is a nice thing; if your application is a
"killer app" and uses the MOP, it will encourage those implementations
that aren't up to speed to implement it.
Of course, there's a certain amount of inertia to overcome...
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Marco Antoniotti <·······@cs.nyu.edu> writes:
> > You and Paul Foley give me the same answer and I agree, but
> > I have to say that I was knowing the existance of that method, but the
> > question that came to my mind was : will this work with "all" CL
> > implementation !!?? (it does with cmucl - when using the pcl package - ).
> > Any advise ?
Side note, since I already answered by mail: The fragment I posted
uses facilities mandated by the AMOP (pp. 214 and 221), hence any
implementation that purports to provide a MOP that conforms to the
AMOP should run the fragment unchanged (modulo package issues, since
implementations differ on the package(s) that they put AMOP-mandated
symbols into).
> At the cost of sounding extremely conservative and backward thinking,
> I would advise you to avoid MOP programming if you want to keep yopur
> programs portable.
That IMHO depends entirely on the level of portability you really
need. Most of the currently supported implementations of CL do
support the MOP (CLISP being one notable exception, though you can
use PCL with CLISP, and get MOP support that way).
There are also still a number of implementations out there that don't
support much of the ANSI CL standard (GCL being one notable example),
yet we don't advise people to restrict their code to ClTl1, in order
to remain portable.
While the ANSI CL standard is a specification of much higher quality
and less ambiguity than the AMOP, I still think that if we want to
advance on the status quo, we need to put our support behind layered
standards such as the AMOP, and fix problems as we go, than to
eternally restrict ourselves to the lowest-common denominator, and
stifle progress. How are both implementations and the AMOP going to
be improved, if they don't see the light of real-world use?
But quite apart from the philisophical arguments, I've used the MOP in
a number of non-trivial real-world applications, and have encountered
only a small number of trivial portability issues across the major
implementations. PLOB!, which makes very heavy use of the MOP, works
in both ACL and LispWorks, though it had to deal with slightly more
portability issues.
So my advice is: If you need the facilities the MOP provides, use
them, and get your vendor/the community to fix any problems that crop
up.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre Mai <····@acm.org> writes:
> There are also still a number of implementations out there that don't
> support much of the ANSI CL standard (GCL being one notable example),
> yet we don't advise people to restrict their code to ClTl1, in order
> to remain portable. [...]
>
> So my advice is: If you need the facilities the MOP provides, use
> them, and get your vendor/the community to fix any problems that crop
> up.
I don't want to come across as unduly negative here, since largely I
agree with the spirit of what you are saying, but I want to at least
note in passing one "small" qualitative difference between these scenarios
which is why I advise caution on the MOP.
Going from CLTL1 to ANSI CL is largely a process of "implementing new
stuff". Going from non-MOP to MOP is largely a process of
"reimplementation of core stuff". My guess is that either an
implementation already largely follows the MOP because it was designed
aroudn it OR, not having been designed around it, would require substantial
change in order to make it MOP compliant.
Of course, the "informatonal" layer that just asks questions about slots
are pretty easy to provide everywhere. But the things that purport to
expose the underpinnings of how certain ANSI CL operations are done are
going to be tricky if the implementation doesn't have those underpinnings.
As a related example, I went to retrofit the ANSI CL condition system onto
Zetalisp, which uses "proceed types" instead of "restarts", and it was quite
tricky because I effectively had to carry around two unrelated kinds of
data that were interthreaded, demand-creating objects on the fly for CL
that are not really there in the Zetalisp condition system. And once in a
while you run into weird binds where things just aren't possible to make
work perfectly at all because you, in effect, get caught in your lie.
It may be that only Symbolics Genera and one or two other implementations
have the kind of age needed to have been designed before AMOP, and perhaps
it's best just to let them fall by the wayside.
Is there a table somewhere of what vendors have what level of MOP support?
Finally having a password to do it, I think I could put one up on the ALU
web site if vendors/implementors sent me (perhaps by private email) a
statement of MOP compliance... assuming there's not already such a central
table I just don't know about.
Kent M Pitman <······@world.std.com> writes:
> Going from CLTL1 to ANSI CL is largely a process of "implementing new
> stuff". Going from non-MOP to MOP is largely a process of
> "reimplementation of core stuff". My guess is that either an
> implementation already largely follows the MOP because it was designed
> aroudn it OR, not having been designed around it, would require substantial
> change in order to make it MOP compliant.
Yes, there is that, and that's why I'd be very careful about adding
the MOP to the core standard, thereby depriving implementations that
didn't implement a MOP, or implemented another MOP, from claiming
conformance to the core standard, especially since there are large
classes of implementations that can be written very well without a
MOP.
> It may be that only Symbolics Genera and one or two other implementations
> have the kind of age needed to have been designed before AMOP, and perhaps
> it's best just to let them fall by the wayside.
[ Continuing from my previous paragraph: ]
Furthermore AFAIK there is some consensous that certain things in the
MOP should be rethought and reworked, in a next-generation MOP, and it
would be dangerous penalizing those implementations that did
pioneering work in that direction (and likely couldn't also be 100%
conforming to the MOP as is). This is similar to the status of
gray-streams, IMHO, where Franz is doing pioneering work with their
simple-streams proposal, in order to get to some form of "GRAY-STREAMS
2.0" standard (although they seem to be able to achieve this without
any incompatabilities with the old gray-streams "standard").
That said, programmers that require the abilities of a MOP to cleanly
implement something should IMHO still feel free to use the MOP as a
foundation, unless their requirements (e.g. portability to Symbolics)
prevent them from doing that.
> Is there a table somewhere of what vendors have what level of MOP support?
> Finally having a password to do it, I think I could put one up on the ALU
> web site if vendors/implementors sent me (perhaps by private email) a
> statement of MOP compliance... assuming there's not already such a central
> table I just don't know about.
Yes some form of documentation for this, and other layered standards,
would be very good thing, especially since this would give some form
of elevated status to those standards, which might give a bit more
momentum for the creation of new layered standards, something which
IMHO the CL community should do more, rather than less.
While I can't speak for other CMU CL developers, personally I'm
committed to moving CMU CL into the direction of full MOP support, and
I consider any reported differences as bugs, that should be fixed
(though some differences are hard to eliminate). That said, limited
resources have kept certain stuff from being fixed for some time...
There is some documentation of differences between CMU CL and the MOP
in the EncyCMUCLopedia. Mostly it is cosmetic stuff and has little
impact on functionality.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre Mai wrote:
> While the ANSI CL standard is a specification of much higher quality
> and less ambiguity than the AMOP, I still think that if we want to
> advance on the status quo, we need to put our support behind layered
> standards such as the AMOP, and fix problems as we go, than to
> eternally restrict ourselves to the lowest-common denominator, and
> stifle progress. How are both implementations and the AMOP going to
> be improved, if they don't see the light of real-world use?
As far as understand what you all have the same discourse. So why hasn't it been
proposed for beeing part of the standard ?
Sorry if you already recive this message but I got a problem with my
connection.
"Pierre R. Mai" wrote:
> Hmmm, doesn't SLOT-DEFINITION-INITARGS together with CLASS-SLOTS do
> what you want? I.e.
>
> (defun get-valid-class-initargs (class)
> (loop for slot in (class-slots class)
> appending (slot-definition-initargs slot)))
>
> should do what you seem to be wanting to do (note that since
> class-slots returns the effective-slot-definition objects, and hence
> takes care of all inheritance issues already.
>
> Regs, Pierre.
You and Paul Foley give me the same answer and I agree, but
I have to say that I was knowing the existance of that method, but the
question that came to my mind was : will this work with "all" CL
implementation !!?? (it does with cmucl - when using the pcl package -
).
Any advise ?