Do not take it globally, please.

I love Phptal and I have not found anything better for PHP so far.

But I still insist aliases would be helpful
Even PHP itself has aliases for some functions.

Hope it makes senseforsomeone.

But I'm not here to argue.
I just wanted to get some experience in such aliasing shared.


On Friday, July 15, 2011, Robert Goldsm <> wrote:
> There will always be examples in every language that attempt to show it is 
> 'better' than another :)
> How about we just agree that for those who want a modifiable syntax and have 
> a desire to skip the verbosity of xml there are many alternative templating 
> systems for PHP - smarty and twig being examples. Personally, I consider them 
> as prime examples of why PHPTal is a good templating language and a warning 
> as to what could happen if we are not careful ;)
> Robert
> On 15 Jul 2011, at 09:22, Anton Andriyevskyy wrote:
>> and also, for guys who love all this looooong and annoying xml things, 
>> attributes etc...
>> Is it not true that setting up routing in concise way like with F3 framework:
>> F3::route('GET /login', 'PageLogin::run');
>> ... is really more clean and readable then 5-lines in XML in configuration 
>> file in Java-word.
>> Nothing against Java, I'm just talking about conciseness in coding....
>> Thanks!
>> Anton
>> On Fri, Jul 15, 2011 at 11:17 AM, Anton Andriyevskyy <> 
>> wrote:
>> Robert, I'm typing ~500...700 symbols in a minute, so it was not told about 
>> typing from my side.
>> Again, my opinion is that when you do something for yourself and you are 
>> very experienced,
>> next level up is shorter notation - then you read & understand & refactor 
>> faster.
>> Well I'm not pushing this change, I'm just interested if someone used to do 
>> so and how it was done.
>> Regards,
>> Anton Andriyevskyy
>> Business Automation & Web Development
>> On Fri, Jul 15, 2011 at 10:59 AM, Robert Goldsmith <> 
>> wrote:
>> I agree with this entirely and would like to add my voice to the 'not 
>> shortening' camp. In an environment where the author is also the maintainer 
>> and the xml is simple and short then I can certainly see the temptation to 
>> try and par the syntax down much like C but years of experience have told me 
>> that the benefits of a more descriptive syntax massively outweigh the slight 
>> inconvenience of having to type more.
>> I regularly have to deal with another language where aliasing is easy to do 
>> and often used to 'save on typing' - SQL. Some of our legacy codebase is 
>> stacked with SQL statements over 100 lines long joining 10 or 12 tables and 
>> where every table has been aliased - 'attributes' is aliased to 'a' while 
>> 'customers' is 'cu' and 'companies' becomes 'c', 'accountDetails' becomes 
>> 'ad' and 'products', 'packages' and 'privileges' become 'p', 'pa' and 'pr'. 
>> Once you have experienced such coding you really appreciate two very simple 
>> points: descriptive is better and there should be one way to do everything.
>> If you are that bothered about having to write long attribute names I can 
>> only assume it is either because you don't want to type as much or you are 
>> trying to fit everything on one line. The former can be solved using any 
>> modern IDE by assigning shortcuts. The latter can be solved by finding a 
>> better (and probably much clearer to read) way to flow elements over 
>> multiple lines. I generally go for each attribute on its own line, indented 
>> 1 level from the node name.
>> Robert Goldsmith
>> On 14 Jul 2011, at 23:05, Darrell Hamilton wrote:
>> > I would argue that compile time type inferencing in Scala is not
>> > comparable to shortening an attribute name.  The intent of the feature
>> > in Scala is not to lessen the number of characters typed, but to
>> > eliminate the need to explicitly specify the type of a variable if
>> > that type is obvious as that could be considered redundant.  A side
>> > effect of this feature just happens to be fewer characters typed.
>> >
>> > I would also argue that the only thing really gained by shortening the
>> > attribute names is fewer characters typed.  After the debate over
>> > whose shortened attribute name has the best balance of conciseness and
>> > clarity, the only thing different is the number of characters typed.
>> > There is no added or simplified functionality.  Additionally, with
>> > respect to refactoring and maintenance, I would argue that it's far
>> > more important to understand the TALES expression assigned to the
>> > attribute than having fewer characters to skip over to get to said
>> > expression.
>> >
>> > Anecdotally, I've found that the volume of characters that comprise
>> > the TALES expressions, especially for things like tal:attributes, so
>> > far out numbers those that comprise the attribute name that saving a
>> > handful of characters is made largely irrelevant.
>> >
>> >
>> > Darrell Hamilton,
>> > Software Developer,
>> > 4over, Inc
>> >
>> > 818-246-1170 ext. 285
>> >
>> >
>> >
>> > On

Anton Andriyevskyy
Business Automation & Web Development

PHPTAL mailing list

Reply via email to