CEDET

On 10/10/2012 07:48 AM, Jesse Alama wrote:
> I recently started to use EIEIO in my ELisp programming.  Coming from
> CLOS, I naturally started to define methods like
>
>    (defmethod foo ((x string) ...))
>
>    (defmethod foo ((x cons)) ...)
>
> But this seems to be unsupported.  It looks like this lack of
> functionality is behind item #2 on the EIEIO wish list ("Method
> dispatch for built-in types").  Has there been any progress on this
> front?

As far as I know, no one has looked into how to make that work.  Most of 
the projects I've worked on have only needed new classes, not extensions 
of built-in types.

I suspect any such feature would need to be done from Emacs core.   I 
suppose it could be faked from the outside, but there would be no useful 
features to inherit from the base type since they have no methods. ;)

Eric

"Eric M. Ludlam" <ericludlam@...> writes:

> On 10/10/2012 07:48 AM, Jesse Alama wrote:
>> I recently started to use EIEIO in my ELisp programming.  Coming from
>> CLOS, I naturally started to define methods like
>>
>>    (defmethod foo ((x string) ...))
>>
>>    (defmethod foo ((x cons)) ...)
>>
>> But this seems to be unsupported.  It looks like this lack of
>> functionality is behind item #2 on the EIEIO wish list ("Method
>> dispatch for built-in types").  Has there been any progress on this
>> front?
>
> As far as I know, no one has looked into how to make that work.  Most of 
> the projects I've worked on have only needed new classes, not extensions 
> of built-in types.
>
> I suspect any such feature would need to be done from Emacs core.   I 
> suppose it could be faked from the outside, but there would be no useful 
> features to inherit from the base type since they have no methods. ;)

I figured that this would probably involve some low-level hacking.
The typical use case that I have in mind is where I define methods
based on a the (primitive) type of the first argument to help clean up
my code.  I find that the three methods

  (defgeneric foo (x))
  (defmethod foo ((x cons)) ...)
  (defmethod foo ((x string)) ...)
  (defmethod foo ((x sequence)) ...)

is more elegant and maintainable, and promotes greater type safety,
more clearly than

  (defun foo (x)
    (cond ((consp x) ...)
          ((stringp x) ...)
          ((sequencep x) ...)
          (t (error "Don't know how to handle '%s'" x))))

or

  (defun foo-cons (x) (...))
  (defun foo-string (x) (...))
  (defun foo-sequence (x) (...))
  (defun foo (x)
    (cond ((consp x) (foo-cons x))
          ...))

>From this perspective, the lack of methods for objects belong to the
base system classes (or types) isn't a problem.

Jesse

-- 
Jesse Alama

On 10/12/2012 05:26 AM, Jesse Alama wrote:
> "Eric M. Ludlam"<ericludlam@...>  writes:
>
>> On 10/10/2012 07:48 AM, Jesse Alama wrote:
>>> I recently started to use EIEIO in my ELisp programming.  Coming from
>>> CLOS, I naturally started to define methods like
>>>
>>>     (defmethod foo ((x string) ...))
>>>
>>>     (defmethod foo ((x cons)) ...)
>>>
>>> But this seems to be unsupported.  It looks like this lack of
>>> functionality is behind item #2 on the EIEIO wish list ("Method
>>> dispatch for built-in types").  Has there been any progress on this
>>> front?
>>
>> As far as I know, no one has looked into how to make that work.  Most of
>> the projects I've worked on have only needed new classes, not extensions
>> of built-in types.
>>
>> I suspect any such feature would need to be done from Emacs core.   I
>> suppose it could be faked from the outside, but there would be no useful
>> features to inherit from the base type since they have no methods. ;)
>
> I figured that this would probably involve some low-level hacking.
> The typical use case that I have in mind is where I define methods
> based on a the (primitive) type of the first argument to help clean up
> my code.  I find that the three methods
>
>    (defgeneric foo (x))
>    (defmethod foo ((x cons)) ...)
>    (defmethod foo ((x string)) ...)
>    (defmethod foo ((x sequence)) ...)
>
> is more elegant and maintainable, and promotes greater type safety,
> more clearly than

If your goal is just adding methods to built-in types, that might be 
possible.  If the check that the input class is an eieio class was 
removed, or if there is a way to verify that 'string' or whatever else 
is a built-in type, the methods aren't strictly tied into the class 
structure.

It is when the method is called that more logic is needed to first check 
for eieio class, followed by some identified built-in type.  It might 
not be too bad.

Remove or augment class check in eieio--defmethod, then somewhere in 
eieio-generic-call reverse the addition of built-in types.

Hmmm.  Could be interesting.  Have you signed papers w/ the FSF for 
contributions to Emacs?

Eric

"Eric M. Ludlam" <ericludlam@...> writes:

> On 10/12/2012 05:26 AM, Jesse Alama wrote:
>> "Eric M. Ludlam"<ericludlam@...>  writes:
>>
>>> On 10/10/2012 07:48 AM, Jesse Alama wrote:
>>>> I recently started to use EIEIO in my ELisp programming.  Coming from
>>>> CLOS, I naturally started to define methods like
>>>>
>>>>     (defmethod foo ((x string) ...))
>>>>
>>>>     (defmethod foo ((x cons)) ...)
>>>>
>>>> But this seems to be unsupported.  It looks like this lack of
>>>> functionality is behind item #2 on the EIEIO wish list ("Method
>>>> dispatch for built-in types").  Has there been any progress on this
>>>> front?
>>>
>>> As far as I know, no one has looked into how to make that work.  Most of
>>> the projects I've worked on have only needed new classes, not extensions
>>> of built-in types.
>>>
>>> I suspect any such feature would need to be done from Emacs core.   I
>>> suppose it could be faked from the outside, but there would be no useful
>>> features to inherit from the base type since they have no methods. ;)
>>
>> I figured that this would probably involve some low-level hacking.
>> The typical use case that I have in mind is where I define methods
>> based on a the (primitive) type of the first argument to help clean up
>> my code.  I find that the three methods
>>
>>    (defgeneric foo (x))
>>    (defmethod foo ((x cons)) ...)
>>    (defmethod foo ((x string)) ...)
>>    (defmethod foo ((x sequence)) ...)
>>
>> is more elegant and maintainable, and promotes greater type safety,
>> more clearly than
>
> If your goal is just adding methods to built-in types, that might be 
> possible.  If the check that the input class is an eieio class was 
> removed, or if there is a way to verify that 'string' or whatever else 
> is a built-in type, the methods aren't strictly tied into the class 
> structure.
>
> It is when the method is called that more logic is needed to first check 
> for eieio class, followed by some identified built-in type.  It might 
> not be too bad.
>
> Remove or augment class check in eieio--defmethod, then somewhere in 
> eieio-generic-call reverse the addition of built-in types.

Ah, I didn't realize that such a route would be available.  Sounds
quite doable.

> Hmmm.  Could be interesting.  Have you signed papers w/ the FSF for 
> contributions to Emacs?

I'd be happy to help.  I haven't signed papers yet with the FSF.  Can
you let me know how to get started with that process?

-- 
Jesse Alama