Re: Patch and test to allow component calls

>http://marc.theaimsgroup.com/?t=103193527500003&r=1&w=2
>
>Summary: We all agree that it would be nice to conveniently match a 
></&> with its starting tag, but differ on the method.

I beg to differ slightly with your summary. As far as I read the 
thread (and the ones before), everyone apart from you Jonathan was ok 
with my solution. But then I would say that... ;)

Anyhow, it was obvious that this "issue" had fallen off the radar, 
hence my suggested patch to force it.


>5. Create a convenient comment marker
>* <%# comment %> - this already works with a single line.

<%# comment %> does not already work. It is broken.

   http://www.masonhq.com/resources/todo/view.html?id=537

Multi-line comments work fine but subject to the same provision that 
the tag ends with a line break.



>3. Allowing the closing tag to either be empty or to have arbitrary text, as
>suggested in Alex's email. This isn't as bad from a parsing standpoint. But I
>have always been against this option and now that I consider it again, am even
>MORE DEAD SET against it. One should not be able to put arbitrary 
>text inside a >language's syntactical tag! It is completely 
>inconsistent with the rest of the
>language, and it will suggest incorrectly to the casual reader that there is
>some sort of matching enforcement with the starting tag.


1. The casual reader is a straw man. Casual readers could make all 
kinds of wrong assumptions if they base them on someone's components 
rather than Mason's documentation or code. (And I'm afraid I'm being 
dense here, but so what if that casual reader concludes that matching 
enforcement is going on? What harm would that lead to)

2. Isn't as bad from parsing standpoint. In fact, is as robust as the 
current regular expression.

3. Requires changes to the parser. Well, yes. The addition of 5 
characters to one line.

4. Why should one not be able to put arbitrary text inside a 
syntactical tag? Is this not putting the horse before the cart? 
Surely you should be able to put whatever the language's syntax 
allows you to put in?

I'm afraid this is going to sound rude, but your reasoning here looks 
like "DON'T LIKE IT". Of course, it may be that I am blinded by the 
fact that I do like it. So if everyone chimes in that this really is 
a show stopper I will accept it and never raise the subject again 
(except in snarky comments in documentation of petulant subclasses of 
Lexer released under MasonX::Samizdat ;)

5. Inconsistency with the rest of the language.

This is a fair point.

However I would argue that component calls with content are 
inconsistent or at the very least have a different nature to other 
syntax tags in mason. It's half like a component or expression tags 
and half like a section tag. And yet unlike the component or 
expression tag, its opening tag is not symmetrical. And unlike the 
section tag, its closing tag is empty.

I presume <%$section> is matched with </%$section> because it would 
be a nightmare to parse all the sections if they ended </%>.

However, as a thought experiment, imagine that the parser could cope 
with </%>. Would it be better to use <%$section></%> (or 
<%$section></%><%#section%> for us weenies) than 
<%$section></%$section>? I would say no - there is actually a benefit 
to clarity that comes from this parsing necessity.

Now compare and contrast:


<& /foo |&>
   <& /bar |&>
   ...
   </&> <%# /bar %>
</&> <%# /foo %>


<&| /foo &>
   <&| /bar &>
   ...
   </& /bar>
</& /foo>


The latter is more succinct than the commented version. It just plain 
reads better. I think it's obvious which is actually more meaningful 
and more useful to a casual mason writer/ lazy perl programmer. And 
it's backwards-compatible and introduces no new syntax.

Plus (and I apologise for bringing up a point from Jonathan's 
previous arguments against) the commented way makes it far more 
likely that comments, opening tags and closing tags could get all 
a-jumble.

Moreover, you would be able to do it either way. Or no way at all. 
The way you feel comfortable with.


Consistency is not the real issue, utility is.

However in the cause of compromise and conciliation to provide that 
veneer of consistency (which should also prevent that casual reader 
getting any ideas), what about?

<&| foo &>bar</& #foo>

>  -    if ( $self->{current}{comp_source} =~ m,\G</&>,gc )
>  +    if ( $self->{current}{comp_source} =~ m,\G</&(\s*#[^>]*)*>,gc )

(Though I still prefer my original suggestion)


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php