[development] Time for a new chapter of an endless debate
Gordon Heydon
gordon at heydon.com.au
Mon Jul 3 03:58:33 UTC 2006
Hi,
Darrel O'Pry wrote:
> On Mon, 2006-07-03 at 12:34 +1000, Gordon Heydon wrote:
>> Hi,
>>
>> Jeremy Epstein wrote:
>>> On 7/3/06, Gordon Heydon <gordon at heydon.com.au> wrote:
>>>> This is just the tip of the ice burg.
>>>>
>>>> It comes down to. What extra does it give us? Nothing!
>>> Not nothing. As chx explained, it gives us consistency, as well as
>>> bringing the handiness of arrays (e.g. all the useful array_*
>>> functions) to more variables.
>> Yes, consistency would be nice. so would been able to the useful
>> array_*()'s.
>>
>>> But now that I think about it, this is not nearly enough of a reason
>>> to justify the amount of code that will get broken (IMHO).
>> I see this as being about same size in changes to the formapi() with no
>> benefits. We would be spinning our wheels for 6 months and not achieving
>> anything.
>>
>> I see this come up every so often, and the people who raise this don't
>> really think about what would be involved in making this change. I don't
>> even think a change like this could be fitted into a normal release cycle.
>
>
> trading -> for [' '] has nothing to do with the way we handle or
> represent data as developers. It won't be a major change to the way in
> which we carry and represent data and designate data handling in Drupal.
Agreed, it only changes how we interact with the data.
> It only affects how the interpreter handles the list of variables we
> store in $node, etc. and how we reference that data as developers. It is
> nothing like form api, and form api 2.0 is lurking out there somewhere
> anyway.
I didn't say it was like the formapi change, but in terms of the scale
of work it is going to be a big, if not bigger.
This change will most likely change every source file in Drupal and
Contrib. Every patch that is in the queue will then need to be re done
and submitted again, and a change like this will take months to check
and test to make sure that nothing was stuffed up, and at the end of all
this work, where would be. At the same position we were before the change.
Granted there are some good performance boosts (Thanks Angie I didn't
think they would be that big) that we will get, but is this enough?
I do not think that we could do this by hand coding, but if we could do
this with a program that will rewrite everything and we also had a very
comprehensive test suite (that would basically test every line of code)
that we could run to make sure that nothing was broken.
Gordon.
>
> !DSPAM:1000,44a88805259161336712104!
>
More information about the development
mailing list