The problem is that the compiler complains that the type DialogText is
undefined in method getall :
(defclass DialogText ()
(...)
)
(defmethod getAll ((txt DialogText)) ...)
But why? (Yes, the one follows the other in this order).
Thanks, people.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> The problem is that the compiler complains that the type DialogText is
> undefined in method getall :
> (defclass DialogText ()
> (...)
> )
>
> (defmethod getAll ((txt DialogText)) ...)
>
> But why? (Yes, the one follows the other in this order).
That is a known defficiency in the current level of CMUCL <-> PCL
integration, i.e. CMU CL will warn of the type being undefined (which
it is at compile-time), but the code will load and work correctly.
This only happens when the defclass and defmethod form are present in
the same compilation-unit, but obviously not when compiling and
loading are interleaved.
There are some hackish ways around that warning, but they have their
own, more worrisome pitfalls, so their use is discouraged, unless you
know exactly what you are doing.
One way to silence the warnings is of course to (compile and) load the
system before compiling it...
Correcting that defficiency is high on my personal todo list, but
sadly it is a bit of intricate hackery, and I haven't found the time
to do much about that... Sorry.
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:
> "Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
>
> > The problem is that the compiler complains that the type DialogText is
> > undefined in method getall :
> > (defclass DialogText ()
> > (...)
> > )
> >
> > (defmethod getAll ((txt DialogText)) ...)
> >
> > But why? (Yes, the one follows the other in this order).
>
> That is a known defficiency in the current level of CMUCL <-> PCL
> integration, i.e. CMU CL will warn of the type being undefined (which
> it is at compile-time), but the code will load and work correctly.
> This only happens when the defclass and defmethod form are present in
> the same compilation-unit, but obviously not when compiling and
> loading are interleaved.
>
> There are some hackish ways around that warning, but they have their
> own, more worrisome pitfalls, so their use is discouraged, unless you
> know exactly what you are doing.
I use some (eval-when (compile eval load) ...) forms to define my classes. This
permit to avoid warnings about undifined types. Is that a "bad" solution ?
* Iban HATCHONDO wrote:
> I use some (eval-when (compile eval load) ...) forms to define my classes. This
> permit to avoid warnings about undifined types. Is that a "bad" solution ?
It's bad in the sense that it causes those classes to be defined as a
side-effect of compiling the file with the definitions in, which might
not be a good thing, especially if the definitions of those classes
are different than some definition which already exists in the system
doing the compiling, for instance if you're trying to compile a new
and incompatible version of a system you already have loaded.
On the other hand it lets you compile the file, and I think any
solution for CMUCL will probably have an equivalent effect?
--tim
Tim Bradshaw <···@cley.com> writes:
> * Iban HATCHONDO wrote:
>
> > I use some (eval-when (compile eval load) ...) forms to define my classes. This
> > permit to avoid warnings about undifined types. Is that a "bad" solution ?
>
> It's bad in the sense that it causes those classes to be defined as a
> side-effect of compiling the file with the definitions in, which might
> not be a good thing, especially if the definitions of those classes
> are different than some definition which already exists in the system
> doing the compiling, for instance if you're trying to compile a new
> and incompatible version of a system you already have loaded.
>
> On the other hand it lets you compile the file, and I think any
> solution for CMUCL will probably have an equivalent effect?
Yes, all current "solutions" amount to the same thing, i.e. doing all
of the defclass effects at compile-time. Whether you do it by
explicitly wrapping the defclass form with an eval-when, or by adding
'COMPILE to the variable PCL::*DEFCLASS-TIMES*, is effectively
irrelevant, though _IF_ you insisted on doing it, I'd rather you added
'COMPILE to PCL::*DEFCLASS-TIMES*, than cluttered your code with the
EVAL-WHENs, thereby not only introducing this risk to CMU CL, but to
all implementations you compile on[1].
BUT, AND HERE COME THE WARNINGS:
- Under no circumstances meddle with PCL::*DEFGENERIC-TIMES* or
PCL::*DEFMETHOD-TIMES*. These will have much more insidious
effects, and if you don't know exactly what you are doing, you can
run into so many traps, that it will make your head spin...
- IF you do the PCL::*DEFCLASS-TIMES* thing, please undo it, before
reporting any bugs, problems, etc. on CMU CL...
Since any file will compile quite correctly, even if it emits loads of
spurious warnings in the process, without these "fixes", I'd rather
people live with the warnings, until such a time that we can properly
silence those warnings...
Regs, Pierre.
Footnotes:
[1] OTOH this might be the wiser choice QA-wise, but that's a
different matter...
--
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