define-layered-method syntax

hi!

i've added various macros over d-l-m, all with syntax like this:

(define-backend-method (present-title pdf) ((self instance-renderer)
(view standard-view))
  ...)

and i tought that d-l-m itself could use this syntax:

(define-layered-method (display-object employment-layer) ((object employer))
  ...)

instead of this:

(define-layered-method display-object :in-layer employment-layer
((object employer))
  ...)

what do you think?

--

-- 
 attila

Re: define-layered-method syntax

On Thu, 19 Jul, 2007 at 23:34:41 +0200, Attila Lendvai wrote:
> 
> and i tought that d-l-m itself could use this syntax:
> 
> (define-layered-method (display-object employment-layer) ((object employer))
>  ...)

Then what about :before, :after methods?  What syntax they would use?

> instead of this:
> 
> (define-layered-method display-object :in-layer employment-layer
> ((object employer))
>  ...)

--
Registered Linux User #124759

Re: define-layered-method syntax

> Then what about :before, :after methods?  What syntax they would use?

the syntax would be almost the same as defmethod, with an exception
that name may be a list, in which case its second element is the layer
name.

this scheme also makes it possible to include keyword arguments later,
when/if the need comes.

i don't want to push it too much, though, just wanted to pop up the idea.

--

-- 
 attila

Re: define-layered-method syntax

On 20 Jul 2007, at 01:12, Attila Lendvai wrote:

>> Then what about :before, :after methods?  What syntax they would use?
>
> the syntax would be almost the same as defmethod, with an exception
> that name may be a list, in which case its second element is the layer
> name.

Common Lisp already has a notion of function names as lists, in the  
form of '(setf function-name). So that case would have to be covered  
as well.

I would not like to go that route because I recall reading other  
discussions about extending acceptable function names, with some  
ideas about other indicators beyond 'setf. I prefer not to create  
opportunities for potential clashes here.

Of course, your suggestion would have the advantage that it saves  
some space. I have already been hit by this a couple of times, trying  
to fit examples of layered methods in papers. ;) In your experience,  
how much better is your proposed syntax?

Cheers,
Pascal

--

-- 
Pascal Costanza, mailto:pc <at> p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium

Re: define-layered-method syntax

> Common Lisp already has a notion of function names as lists, in the
> form of '(setf function-name). So that case would have to be covered
> as well.

oh, heh, to be honest i didn't think of that...

> Of course, your suggestion would have the advantage that it saves
> some space. I have already been hit by this a couple of times, trying
> to fit examples of layered methods in papers. ;) In your experience,
> how much better is your proposed syntax?

well, in situations like this "better" is a question of taste... :) i
like the proposed syntax more for its compactness and somehow my
paren-matcher (brain) can also pick up the layer name better this way.
it didn't cause me any headaches yet, but i have to admit, that i've
never wanted to work with layered setf methods... but handling them
should be doable. for example:

(d-l-m ((setf foo) some-layer) (new-value arg1) ...)

but either case, i think we should avoid playing dirty tricks with
things like (setf foo some-layer)

the background is that recently i had to reach under my d-l-m wrappers
and define a layered method on a combination of a backend and a form,
which my wrapper macros didn't support. and i got used to them so much
that the "barebone" d-l-m with its :in-layer just felt strange.
therefore this proposal/question was born.

--

-- 

PATCH: Better print-object for layers: print the layer precedence list for unnamed layers

hth,
--

-- 
 attila

_______________________________________________
closer-devel mailing list
closer-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

Re: define-layered-method syntax

On 20 Jul 2007, at 02:00, Attila Lendvai wrote:

>> Common Lisp already has a notion of function names as lists, in the
>> form of '(setf function-name). So that case would have to be covered
>> as well.
>
> oh, heh, to be honest i didn't think of that...
>
>> Of course, your suggestion would have the advantage that it saves
>> some space. I have already been hit by this a couple of times, trying
>> to fit examples of layered methods in papers. ;) In your experience,
>> how much better is your proposed syntax?
>
> well, in situations like this "better" is a question of taste... :) i
> like the proposed syntax more for its compactness and somehow my
> paren-matcher (brain) can also pick up the layer name better this way.
> it didn't cause me any headaches yet, but i have to admit, that i've
> never wanted to work with layered setf methods... but handling them
> should be doable. for example:
>
> (d-l-m ((setf foo) some-layer) (new-value arg1) ...)

That's still an easy case. I am more concerned about this:

(d-l-m (setf foo) (...) ...)

Is this a method for '(setf foo) in the layer 't, or is this a method  
for 'setf in the layer 'foo?

Re: PATCH: Better print-object for layers: print the layer precedence list for unnamed layers

_______________________________________________
closer-devel mailing list
closer-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

Re: define-layered-method syntax

> So in order to avoid clashes of naming conventions, I would have to
> require that layers are always specified, even when they are just 't.
> I'd find that more awkward than having to say :in-layer some-layer.

after reading your mail i think you are right, my proposed syntax
could be confusing in some situations.

> have sketched above. As a small workaround for the wordiness of the
> keyword, I could accept :in as an alternative for :in-layer. Would
> that help at least a little?

i was hesitant for a moment, but it's define-LAYERED-method after all,
so what else would :in mean?

> Please also keep in mind that define-layered-method already provides
> an extension for accessing the current layer:
>
> (d-l-m foo :in-layer (l some-layer) (...) ...)
>
> This binds the current layer to the local variable l. This is, for
> example, useful when using call-next-method and you want to change
> some of the parameters.

i remember looking for that feature once, thanks for the heads-up! :)

--

-- 
 attila

Re: PATCH: Better print-object for layers: print the layer precedence list for unnamed layers

> OK, this looks good, I will add this.

thanks!

> Two questions:
>
> - Does it matter if any of the layers in the precedence list are anonymous?

i think all i wanted to know is a list of enabled layers...

> - Shouldn't print-object additionally say that the layer itself is
> anonymous?

...but any information over that can be potentially useful. when i
need even more information, then i usually customize the slime
inspector.

i've also sent a patch to sbcl-devel that makes sbcl print the object
identity for unnamed classes, which was also a must-have when i was
debugging a problem i was looking for. but it's not in the official,
yet.

--

-- 
 attila