Delivery and type-of

Hello,

The delivery manual tells :

"If you use typep , typecase , and subtypep to discriminate between types,
Delivery is forced to keep additional information in the delivered image."
(Delivery User Guide 3.2.6)

Anybody knows if 'type-of' shares the same restriction (or other delivery
restrictions) ?

Thanks

Denis


-------------------------------------------------------
Denis Pousseur
70 rue de Wansijn
1180 Bruxelles, Belgique

Tel : 32 (0)2 219 31 09
Mail :  denis.pousseur@gmail.com
-------------------------------------------------------

Re: Delivery and type-of

Hello Denis,

| The delivery manual tells :
|
| "If you use typep , typecase , and subtypep to discriminate between
| types, Delivery is forced to keep additional information in the
| delivered image." (Delivery User Guide 3.2.6)
|
| Anybody knows if 'type-of' shares the same restriction (or other
| delivery restrictions) ?

I consider type-of to be a dangerous replacement. I am not sure if it result
in a smaller code but is definitely more error-prone. If generic function do
not suit you, you can hardly dispense with typep and typecase.
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru

Re: Delivery and type-of

Unable to parse email body. Email id is 7187

Re: Delivery and type-of

Hi Dimitry, Hi Martin,

I thought that something like

(defun myclass-p (thing) (eq (type-of thing) 'myclass))

Is less expansive than

(defmethod myclass-p ((self myclass)) t)
(defmethod myclass-p ((self t)) nil)

Because there is no need of a generic function and 2 methods...

It is in a environment where the classes are *certainly* used and, to this
point of view, delivery can't do anything for me. But, maybe, there is some
other good reasons to use methods rather than calls to type-of (for example
the necessity for the system to keep the class name symbols ?). In this case
I will replace my functions.

Thanks

Denis




Le 20/11/07 17:45, « [NOM] » <[ADRESSE]> a écrit :

> 
>>>>>> On Tue, 20 Nov 2007 16:20:54 +0100, Denis Pousseur said:
>> 
>> Hello,
>> 
>> The delivery manual tells :
>> 
>> "If you use typep , typecase , and subtypep to discriminate between types,
>> Delivery is forced to keep additional information in the delivered image.."
>> (Delivery User Guide 3.2.6)
>> 
>> Anybody knows if 'type-of' shares the same restriction (or other delivery
>> restrictions) ?
> 
> It depends on what you do with the result.
> 
> Also, I think the manual might be misleading here, because there are no large
> functions or tables within the implementation of these functions.
> 
> The problem is more general: referencing the name of a type (i.e. a symbol) in
> code means that delivery cannot remove that type even if it is never used
> anywhere else.  E.g. if you have code like this:
> 
> (cond ((typep x 'class1) ...)
>       ((typep x 'class2) ...)
>       ...
>       ((typep x 'class1000) ...))
> 
> then delivery would keep all of the classes class1,...,class100 even if
> nothing else references them.  This could also happen with type-of if you did
> something like this:
> 
> (let ((type (type-of x)))
>   (cond ((eq type 'class1) ...)
>         ((eq type 'class2) ...)
>         ...
>         ((eq type 'class1000) ...)))
> 
> Rewriting the cond by defining a method specialized for each class would allow
> any unused classes to be removed because each method is a separate function.

-------------------------------------------------------
Denis Pousseur
70 rue de Wansijn
1180 Bruxelles, Belgique

Tel : 32 (0)2 219 31 09
Mail :  denis.pousseur@gmail.com
-------------------------------------------------------

Re: Delivery and type-of

>>>>> On Tue, 20 Nov 2007 18:20:39 +0100, Denis Pousseur said:
> 
> Hi Dimitry, Hi Martin,
> 
> I thought that something like
> 
> (defun myclass-p (thing) (eq (type-of thing) 'myclass))
> 
> Is less expansive than
> 
> (defmethod myclass-p ((self myclass)) t)
> (defmethod myclass-p ((self t)) nil)
> 
> Because there is no need of a generic function and 2 methods...

Yes, the defun would be slightly smaller...but I suspect you would need 1000's
of classes for it to make much difference overall.


> It is in a environment where the classes are *certainly* used and, to this
> point of view, delivery can't do anything for me. But, maybe, there is some
> other good reasons to use methods rather than calls to type-of (for example
> the necessity for the system to keep the class name symbols ?). In this case
> I will replace my functions.

The symbol will not make any difference here because the system always keeps
the class name symbols if the class is kept.

Note that the defun using type-of code would be wrong if you define

(defclass mysubclass (myclass) ...)

That might be one of the "error-prone" cases that Dmitriy was thinking about.

__Martin


> 
> Thanks
> 
> Denis
> 
> 
> 
> 
> Le 20/11/07 17:45, « [NOM] » <[ADRESSE]> a écrit :
> 
> > 
> >>>>>> On Tue, 20 Nov 2007 16:20:54 +0100, Denis Pousseur said:
> >> 
> >> Hello,
> >> 
> >> The delivery manual tells :
> >> 
> >> "If you use typep , typecase , and subtypep to discriminate between types,
> >> Delivery is forced to keep additional information in the delivered image."
> >> (Delivery User Guide 3.2.6)
> >> 
> >> Anybody knows if 'type-of' shares the same restriction (or other delivery
> >> restrictions) ?
> > 
> > It depends on what you do with the result.
> > 
> > Also, I think the manual might be misleading here, because there are no large
> > functions or tables within the implementation of these functions.
> > 
> > The problem is more general: referencing the name of a type (i.e. a symbol) in
> > code means that delivery cannot remove that type even if it is never used
> > anywhere else.  E.g. if you have code like this:
> > 
> > (cond ((typep x 'class1) ...)
> >       ((typep x 'class2) ...)
> >       ...
> >       ((typep x 'class1000) ...))
> > 
> > then delivery would keep all of the classes class1,...,class100 even if
> > nothing else references them.  This could also happen with type-of if you did
> > something like this:
> > 
> > (let ((type (type-of x)))
> >   (cond ((eq type 'class1) ...)
> >         ((eq type 'class2) ...)
> >         ...
> >         ((eq type 'class1000) ...)))
> > 
> > Rewriting the cond by defining a method specialized for each class would allow
> > any unused classes to be removed because each method is a separate function.
> 
> -------------------------------------------------------
> Denis Pousseur
> 70 rue de Wansijn
> 1180 Bruxelles, Belgique
> 
> Tel : 32 (0)2 219 31 09
> Mail :  denis.pousseur@gmail.com
> -------------------------------------------------------
> 
>

Re: Delivery and type-of




Le 20/11/07 19:18, « [NOM] » <[ADRESSE]> a écrit :

> Note that the defun using type-of code would be wrong if you define
> 
> (defclass mysubclass (myclass) ...)


Naturally : I use this only for very specific situations (the most
specialized descendant of a class)

Thanks for your help !

Denis


-------------------------------------------------------
Denis Pousseur
70 rue de Wansijn
1180 Bruxelles, Belgique

Tel : 32 (0)2 219 31 09
Mail :  denis.pousseur@gmail.com
-------------------------------------------------------