Re: SCM_SMOB_TAG smob abstraction

[Dirk Herrmann <dirk@ida.ing.tu-bs.de>]

On 8 Sep 1999, Mikael Djurfeldt wrote:

> Jorgen "forcer" Schaefer <forcer@mindless.com> writes:
> 
> > To faciliate an abstraction for smob tag retrieval similar to the
> > SCM_SMOB_DATA functions, it would be nice to have a SCM_SMOB_TAG
> > macro (patch below).
> 
> I'm not so sure about that.
> 
> The type of the object should probably not be regarded as part of the
> smob abstraction but rather as a part of the type system.
> 
> There already exists a macro for extracting the type of this kind of
> objects: SCM_TYP16.

I have to admit that I can not quite understand this argument.  There are
several reasons why a SCM_SMOB_TAG would be desirable:

* readability:  The semantics of SCM_SMOB_TAG is immediately clear to a
  reader of the corresponding code.

* if the smob system is to be changed it is easier.  For example,
  sometimes the number of bits for smobs is to be changed (if I remember
  correctly).  Then, it might just be a macro change, while otherwise you
  have to go through all SCM_TYP16 places to see if they need fixing.

* you can better search for places where smob tags are read.

In contrast, SCM_TYP16 is used in several different places.

In any way, if one day it appears to be wrong to have a SCM_SMOB_TAG
macro, it is simple to just do a "sed 's/SCM_SMOB_TAG/SCM_TYP16/g'".  It's
not that simple to do the other way around.

What objections are there to have abstractions for concepts _within_ the
type system?

Best regards,
Dirk Herrmann