what does "inheritance" mean in the context of CLIM?
what is the correct interpretation of these several passages in the documentation:
--------------
(6.1.5) http://www.xanalys.com/software_tools/reference/lwl41/climuser/GUID_98.HTM
...
The set of presentation types forms a type lattice, an extension of the
Common Lisp CLOS type lattice. When a new presentation type is defined
as a subtype of another presentation type, it inherits all the
attributes of the supertype except those explicitly overridden in the definition.
(7.1.1) http://www.xanalys.com/software_tools/reference/lwl41/climuser/GUID_119.HTM
...
Presentation type inheritance translates the parameters of the subtype
into a new set of parameters for the supertype, and translates the
options of the subtype into a new set of options for the supertype.
(6.6) http://www.xanalys.com/software_tools/reference/lwl41/climuser/GUID_116.HTM
presentation-type-options
Returns the list of options specified when the presentation type or
presentation type abbreviation whose name is type-name was defined. This
does not include the standard options unless the presentation-type
definition mentioned them explicitly.
---------------
where the implementation produces the following (excerpted from the
bicycle-gearing example):
(define-presentation-type gear ()
:inherit-from '(integer 1))
==>
CLIM-USER::GEAR
(macroexpand
'(with-presentation-type-parameters (integer type) clim-internals::low))
==>
(LET NIL
(MULTIPLE-VALUE-BIND (#:PARAMETERS)
(COND ((ATOM TYPE) (VALUES NIL)) ((ATOM (CAR
TYPE)) (VALUES (CDR TYPE)))
(T (VALUES (CDAR TYPE))))
(CLIM-UTILS:BIND-TO-LIST (&OPTIONAL (CLIM-INTERNALS::LOW '*)
(CLIM-INTERNALS::HIGH '*))
#:PARAMETERS
CLIM-INTERNALS::LOW)))
(macroexpand
'(with-presentation-type-parameters (gear type) clim-internals::low))
==>
(LET NIL
(MULTIPLE-VALUE-BIND (#:PARAMETERS)
(COND ((ATOM TYPE) (VALUES NIL)) ((ATOM (CAR
TYPE)) (VALUES (CDR TYPE)))
(T (VALUES (CDAR TYPE))))
(CLIM-UTILS:BIND-TO-LIST NIL #:PARAMETERS CLIM-INTERNALS::LOW)))
(ignoring the package)
it would appear that inheritance is with respect to the type lattice,
but not the structural properties. even where one of the parameters is
restricted. is that the intention?
"james anderson" <··············@setf.de> wrote in message
······················@setf.de...
>
> what does "inheritance" mean in the context of CLIM?
>
> what is the correct interpretation of these several passages in the
documentation:
I must be being stupid this morning, but I don't understand what the
real question is.
What CLIM is trying to do is implement "parameterized types". So in
the following example, the 'gear' ptype is inheriting from the 'integer'
ptype,
which has parameters 'low' and 'high'. Are you asking the question,
"Should 'gear' have inherited the 'low' and 'high' parameters?" If so, I
think the answer should be yes, even tho' the code obviously does not
do this.
Of course, I wrote all this stuff (code and documentation) a dozen years
ago,
and there are several explanations for the mismatch you observe:
(1) I forgot that I really meant it to have this behavior for some good
reason.
(2) I didn't understand parameterized types well enough at the time, and
got it wrong.
(3) There's a bug in CLIM.
Each of these explanations is equally likely, I'm afraid.
> --------------
>
> (6.1.5)
http://www.xanalys.com/software_tools/reference/lwl41/climuser/GUID_98.HTM
> ...
> The set of presentation types forms a type lattice, an extension of the
> Common Lisp CLOS type lattice. When a new presentation type is defined
> as a subtype of another presentation type, it inherits all the
> attributes of the supertype except those explicitly overridden in the
definition.
>
>
> (7.1.1)
http://www.xanalys.com/software_tools/reference/lwl41/climuser/GUID_119.HTM
> ...
> Presentation type inheritance translates the parameters of the subtype
> into a new set of parameters for the supertype, and translates the
> options of the subtype into a new set of options for the supertype.
>
>
> (6.6)
http://www.xanalys.com/software_tools/reference/lwl41/climuser/GUID_116.HTM
> presentation-type-options
>
> Returns the list of options specified when the presentation type or
> presentation type abbreviation whose name is type-name was defined. This
> does not include the standard options unless the presentation-type
> definition mentioned them explicitly.
>
> ---------------
>
> where the implementation produces the following (excerpted from the
> bicycle-gearing example):
>
> (define-presentation-type gear ()
> :inherit-from '(integer 1))
> ==>
> CLIM-USER::GEAR
>
> (macroexpand
> '(with-presentation-type-parameters (integer type) clim-internals::low))
> ==>
> (LET NIL
> (MULTIPLE-VALUE-BIND (#:PARAMETERS)
> (COND ((ATOM TYPE) (VALUES NIL)) ((ATOM (CAR
> TYPE)) (VALUES (CDR TYPE)))
> (T (VALUES (CDAR TYPE))))
> (CLIM-UTILS:BIND-TO-LIST (&OPTIONAL (CLIM-INTERNALS::LOW '*)
> (CLIM-INTERNALS::HIGH '*))
> #:PARAMETERS
> CLIM-INTERNALS::LOW)))
>
> (macroexpand
> '(with-presentation-type-parameters (gear type) clim-internals::low))
> ==>
> (LET NIL
> (MULTIPLE-VALUE-BIND (#:PARAMETERS)
> (COND ((ATOM TYPE) (VALUES NIL)) ((ATOM (CAR
> TYPE)) (VALUES (CDR TYPE)))
> (T (VALUES (CDAR TYPE))))
> (CLIM-UTILS:BIND-TO-LIST NIL #:PARAMETERS CLIM-INTERNALS::LOW)))
>
> (ignoring the package)
> it would appear that inheritance is with respect to the type lattice,
> but not the structural properties. even where one of the parameters is
> restricted. is that the intention?
Scott McKay wrote:
>
> "james anderson" <··············@setf.de> wrote in message
> ······················@setf.de...
> >
> > what does "inheritance" mean in the context of CLIM?
> >
> > what is the correct interpretation of these several passages in the
> documentation:
>
> I must be being stupid this morning, but I don't understand what the
> real question is.
>
> What CLIM is trying to do is implement "parameterized types". So in
> the following example, the 'gear' ptype is inheriting from the 'integer'
> ptype,
> which has parameters 'low' and 'high'. Are you asking the question,
> "Should 'gear' have inherited the 'low' and 'high' parameters?" If so, I
> think the answer should be yes, even tho' the code obviously does not
> do this.
yes, that is what i was trying to ask: should not low and high be
lexically apparent within the body of presentation functions which are
specialized on a presentation subtype of integer?
likewise, shouldn't the same apply to the option and parameter macros?
>
> Of course, I wrote all this stuff (code and documentation) a dozen years
> ago,
> and there are several explanations for the mismatch you observe:
> (1) I forgot that I really meant it to have this behavior for some good
> reason.
> (2) I didn't understand parameterized types well enough at the time, and
> got it wrong.
> (3) There's a bug in CLIM.
> Each of these explanations is equally likely, I'm afraid.
>
[1] seems the most effective to answer first.
what are the prospects of getting the "canonical" source for the "base"
clim implementation?
is there any other way to reconstruct what the implemention is intended
to do?
...
In article <·················@setf.de>,
james anderson <··············@setf.de> writes:
> what are the prospects of getting the "canonical" source for the "base"
> clim implementation?
You'd have to contact your vendor to see about a source license.
If, on the other hand, you're asking about the "canonical" source being made
generally available, the prospects are pretty much zip, zero, nada. The
copyright issues on the original implmentation are so complex that no one has
been able to unravel them. Hence, the McCLIM project, where we're trying to
reimplement the thing instead of improving the existing version.
http://www.mikemac.com/mikemac/McCLIM/index.html
Mike McDonald
·······@mikemac.com
On Wed, 10 Apr 2002 13:16:38 GMT, Scott McKay <···@attbi.com> wrote:
>
>"james anderson" <··············@setf.de> wrote in message
>······················@setf.de...
>>
>> what does "inheritance" mean in the context of CLIM?
>>
>> what is the correct interpretation of these several passages in the
>documentation:
>
>I must be being stupid this morning, but I don't understand what the
>real question is.
>
>What CLIM is trying to do is implement "parameterized types". So in
>the following example, the 'gear' ptype is inheriting from the 'integer'
>ptype,
>which has parameters 'low' and 'high'. Are you asking the question,
>"Should 'gear' have inherited the 'low' and 'high' parameters?" If so, I
>think the answer should be yes, even tho' the code obviously does not
>do this.
I didn't come to that conclusion when implementing presentation types
for McCLIM. Parameters and options are not slots, they are parameters
as in types defined by DEFTYPE. In DEFTYPE'ed types there is no
notion of inheriting the syntax of the base type(s); indeed there is no
notion of structural inheritance at all.
"Subtyping is not subclassing" and all that...
>Of course, I wrote all this stuff (code and documentation) a dozen years
>ago,
>and there are several explanations for the mismatch you observe:
> (1) I forgot that I really meant it to have this behavior for some good
>reason.
> (2) I didn't understand parameterized types well enough at the time, and
> got it wrong.
> (3) There's a bug in CLIM.
>Each of these explanations is equally likely, I'm afraid.
If there's a bug, I think it's that presentation types try to be like
Common Lisp types while adding some nifty CLOS features, but
CLOS-style inheritance is an awkward fit for many of the subtype
relationships in the CL type lattice. I think presentation types are
cool, but I'd think they'd be cooler if they were defined only in
terms of classes and generic functions with protocols for determining
and, or, not and subtyping relationships.
Tim