> >If you use delimiter names that are speaking, it would get very readable:
>>
>> define delimiter pathItem as "/"
>> define delimiter fileSuffixItem as "."
>>
>
> > put the last fileSuffixItem of the last pathItem of theFile into theSuffix
>
> We could auto-append "item" to every chunk type that is user-defined, but
>I think that's be a bit too restrictive. But we might make that a
>guideline: "Name all your delimiters "*_Item" to make sure they don't
>conflict with future delimiter names."?
But it don't have to be items, especially if they are regular
expressions. You may call it "term" or "block" or "...line" or
"...part" and they still are readable.
> > put the last item delimited by "/" of the last item delimited by "."\
>> of theFile into theSuffix
>
> Actually, yes. We'd just have to decide on the scope of such a delimiter.
>The only thing that seems feasible is, again, local variable, that is
>handler scope.
How about script scope?
> >It would also be easy to expand to regexp delimiter (in the syntax
>>Uli proposed in another mail):
>> define delimiter block as "<" & some text & ">"
>
>regexp delimiters were Anthony's idea.
Anthony had the idea to have regexp delimiters, but Uli had the idea
for this kind of syntax.
>But we could again allow for expressions here. But again, I'd prefix
>this with "expression" to set it apart from using a chunk expression
>to define a multi-character delimiter:
>
> define delimiter block as expression "<" & some text & ">"
That would make it easier for the parser, but it would not add so
much to readability. I can live with or without equally well. Make it
optional!?!
Regards
R�diger
--------------------------------------------------------------------
| Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
| PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
--------------------------------------------------------------------
