Hi Greg,
I would like to reiterate that for some of us, the plot is
at this stage getting repetitive. The RFC needs updating, in
my humble opinion, before this discussion can go anywhere.
>You will find my annoyance level quite high when words
like "honesty"
>are thrown about as if there is any lack of honesty.
This kind of
>insinuation is what often makes me lose interest in
participating in
>open source, if only for a moment.
Matthew picked words badly perhaps, but the intended meaning
was I assume to the lack of backup or real evidence being
attached to some statements. In some cases, such statements
were simply misleading, or outright wrong. This isn't to
question the honesty of those making such statements of
course.
>Let me be quite blunt: where the lies at?
I don't remember exact emails, but let's call them simple
misstatements. Not the result of dishonesty.
>The truth is that I have been bouncing these and other
ideas off of many
>developers off of pear-dev for a while, and gradually
expanding the
>circle of people I talked to about them in order to
refine them and get
>a better sense of both the advantages and especially of
the problems.
>Yes, many of my ideas have been cut from the RFC over
time, this is how
>team and real community collaboration works. In
addition, lots of
>tweaks or new ideas from others have made their way into
the RFC.
I don't see the relevancy?
I think everyone knows the RFC was a collaboration among a
number of intelligent experienced people. What is relevant
is that the collaboration itself was not accessible by many
of us - including me with my 0 Karma ;). Nobody else got the
benefit of your discussions, which inevitably means we
needed to rehash everything, challenge your assumptions,
question your approach, and above all else request actual
proof of the RFCs worth. It's the "proof" part
holding up several of us. We can rationalise things all day,
but without some form of proof it's not possible to make an
informed decision - and therefore we will not make that
decision yet.
My experience so far is like watching a big blank wall. You
talk to the wall, but you're left with the impression the
wall doesn't really want to talk back. Finally you realise
its responses were just echos from something that happened
earlier but got a bit muddled while in transit, and go find
something more interesting to watch - like mud.
> Arnaud is the official RFC sponsor from the PEAR group,
and his (it
> turns out rather naive) assumption was that by
presenting the RFC in its
> current state, you developers would be capable of
examining it from the
> same perspective that he and other PEAR group members
examined it, as a
> new idea to be considered rationally and carefully, to
be questioned and
> taken as a work in progress.
Arnaud is not naive and I welcome the idea of opening up
RFCs for comment. However, the RFC has been carefully
examined, considered and found wanting. Not wanting in all
areas incidentally - but in one or two very specific places
where many of us, myself and Matthew included, have
requested additional backup. I think that most of the RFC is
in fact not disputed very much?
I'm quite capable of being rational and careful, thanks.
Unfortunately being rational means we're cursed with an
inability to make decisions based solely on iffy opinions
and conjecture. Obviously since I was not part of the
original discussion and debate which led to the RFC, I am
unable to share this perspective from the lofty heights. How
does it look up there? Is it true that Speed Freaks have
fluffy white wings? ;)
I'm kidding, of course.
>1) include allfiles.php and start using the app
>2) use include_path and autoload
>3) require full path for needed files, or some other
customizable solution
We're aware of the methods - but the devil's in the details
where we're not convinced. No amount of emails will change
that until the RFC is updated as requested, and some amount
of evidence/solutions produced for the remaining contentious
points. Pure opinion is just not all that convincing right
now, regardless of how well respected it may be.
> In addition, by removing hard-coded require_once
statements, it allows
> the mega-speed freak to do the ultimate optimization:
mash all the
> needed files into a single php file - WITHOUT code
modification, which
> also means that upgrading the contents of the file is a
simple task (no
> need to muck about for new require_once statements
added in the code
> contents for some new driver implementation or
whatnot).
It sounds, and always has, like a completely unnecessary
complication which many developers would rectify with a
build tool like Phing or Ant if warranted. If such folk
can't use a build tool, it's not my problem, so why should I
cater to them? Why would a speed freak *not* want to muck
around with a build tool? And why should a minority need be
used as a sledgehammer to justify anything?
To finish off here.
You posted an RFC. You got comments. The RFC process worked.
Problem, is that it worked too well! Lots of people
questioned, poked, disagreed, challenged, agreed, raised
concerns, used four-letter words etc. The problem is that
many of these were not addressed, or were answered with
outdated information, or weren't explained properly, or
lacked any specific acknowledgment of disadvantages etc. All
of which quickly got very confusing, frustrating, and
pointless.
Which is why I started the email with "The RFC needs
updating, in my humble opinion, before this discussion can
go anywhere". Because even this response is likely
completely pointless since it contributes nothing new to the
debate except as an urging to get the RFC updated.
Best regards,
Paddy
Pádraic Brady
http://blog.astrumfutura
.com
http://www.patternsforp
hp.com
----- Original Message ----
From: Greg Beaver <greg chiaraquartet.net>
To: Matthew Weier O'Phinney <mweierophinneygmail.com>
Cc: PEAR developer mailinglist <pear-devlists.php.net>
Sent: Saturday, July 21, 2007 2:39:33 AM
Subject: Re: [PEAR-DEV] Why change require_once? A brief
explanation of motives
Matthew Weier O'Phinney wrote:
> I think this is a reasonable goal. I'm not convinced
that removing
> require_once is the solution, however.
>
> Frankly, I'm seeing an RFC that does the following:
>
> * Trades one known and widely used language construct,
require_once,
> for another, autoloading;
> * with the purpose of saving 15% of a fraction of the
execution
> overhead;
> * and solving an edge case of installation (phar);
> * and making tracking down *where* and *when* a class
file is loaded
> much more difficult.
>
> Basically, I think that while the goals of the RFC are
well-stated, the
> *whys* behind them have not been (or have not been
backed up with
> sufficient evidence), and that they have neglected to
consider other
> elements of the equation.
>
> All that said, I'm not totally against this any more.
Like Paddy, I'm
> coming around. I just think that there's more
discussion needed, and
> more honesty and transparency from all parties.
Hi Matthew and all,
You will find my annoyance level quite high when words like
"honesty"
are thrown about as if there is any lack of honesty. This
kind of
insinuation is what often makes me lose interest in
participating in
open source, if only for a moment.
Let me be quite blunt: where the lies at?
The truth is that I have been bouncing these and other ideas
off of many
developers off of pear-dev for a while, and gradually
expanding the
circle of people I talked to about them in order to refine
them and get
a better sense of both the advantages and especially of the
problems.
Yes, many of my ideas have been cut from the RFC over time,
this is how
team and real community collaboration works. In addition,
lots of
tweaks or new ideas from others have made their way into the
RFC.
Arnaud is the official RFC sponsor from the PEAR group, and
his (it
turns out rather naive) assumption was that by presenting
the RFC in its
current state, you developers would be capable of examining
it from the
same perspective that he and other PEAR group members
examined it, as a
new idea to be considered rationally and carefully, to be
questioned and
taken as a work in progress.
Now, for technical stuff: the RFC does not trade
require_once for
autoloading, it removes require_once in favor of giving
users the
flexibility of choosing whether to use three possible ways
to load class
files:
1) include allfiles.php and start using the app
2) use include_path and autoload
3) require full path for needed files, or some other
customizable solution
In addition, by removing hard-coded require_once statements,
it allows
the mega-speed freak to do the ultimate optimization: mash
all the
needed files into a single php file - WITHOUT code
modification, which
also means that upgrading the contents of the file is a
simple task (no
need to muck about for new require_once statements added in
the code
contents for some new driver implementation or whatnot).
I am out of time, so I must send this message. Please
understand that I
have about 1 hour every 4 days in which to send messages, I
can read
messages every day though. I can't give you and PEAR
anything more
until mid-August, I'm very sorry about this!!
Thanks,
Greg
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php
____________________________________________________________
________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
|
