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
<rgoldsm...@names.co.uk>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
> > 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
>
_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to