Marcel Grunauer wrote:
>
> Hey Brian,
>
> > Neil and I came up with this patch that makes your code sooooo much
> > better. You can use it later today when Inline::Files hits the CPAN.
> >
> > ---8<---
> > --- bad Fri May 25 11:10:33 2001
> > +++ good Fri May 25 11:18:02 2001
>
> I take it you don't like it, then? :)
Marcel,
Actually when I first saw it, I thought 'cool'. But as I looked closer
it just didn't seem to simplify anything. And as I hash it around in my
head, I just can't come up with anything really nice using attributes.
Inline works well at so many levels. It really scales surprisingly well.
And it's so clean at this point, I just can't see that rearranging it to
look different would gain anything.
I don't like to add stuff to Inline without several good reasons. I
mainly look for things to take away.
Inline::Files takes away the '__END__' statement but that's not my real
rationale for it. It adds semantic consistency and the promise of better
debugging. Those are valuable.
>
> Oh well, it wasn't so pretty, and it only would have made sense with
> default options of Inline (as this kind of syntax probably wouldn't
> have allowed you to change options easily - and ease of use was the
> idea here).
True. True.
>
> Never mind, I'm just going attribute-crazy at the moment.
I don't blame you. Attributes are cool. I actually want Damian to
reconsider my request that Inline::Files markers can have attributes.
Like:
__FILE__ :attr1 :attr2(value)
You could add extra semantics to files...
Cheers, Brian
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
