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 <x.meg...@gmail.com>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 <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