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
> darre...@4over.com
> 818-246-1170 ext. 285
> 
> 
> 
> On Thu, Jul 14, 2011 at 12:26 PM, Anton Andriyevskyy <x.meg...@gmail.com> 
> wrote:
>> Darrell, all this sounds good, but it the same ends up that we want to have
>> more concise html with shorter attributes.
>> Concise (but still readable) always wins - a good example would be Scala
>> programming language where compiler infers many things
>> automatically but still keeps things strongly typed, and this ends up with
>> very concise syntax, so I'm remaining
>> sure that conciseness is good and simplifies many things. In case of phptal,
>> not only writing of html becomes faster,
>> but also reading - which is very important when you do refactoring and
>> maintenance.
>> Regards,
>> Anton Andriyevskyy
>> Business Automation & Web Development
>> 
>> 
>> On Thu, Jul 14, 2011 at 8:47 PM, <s...@canterris.com> wrote:
>>> 
>>> Thank you for contacting Canterris.  I???m currently out of the office
>>> until July 25.  Please feel free to contact Will Freemen
>>> (w...@canterris.com) or Canterris Technical Support (supp...@canterris.com)
>>> for any support requests.
>>> 
>>> _______________________________________________
>>> PHPTAL mailing list
>>> PHPTAL@lists.motion-twin.com
>>> http://lists.motion-twin.com/mailman/listinfo/phptal
>> 
>> 
>> _______________________________________________
>> PHPTAL mailing list
>> PHPTAL@lists.motion-twin.com
>> http://lists.motion-twin.com/mailman/listinfo/phptal
>> 
>> 
> 
> _______________________________________________
> PHPTAL mailing list
> PHPTAL@lists.motion-twin.com
> http://lists.motion-twin.com/mailman/listinfo/phptal


_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to