I didn't put any work in here and I agree with him 100%. Namespaces have
been incredibly useful for me. Now that I'm using them I would not want
to do without them.

As far as bundling, my application (over 11,000 lines now) did use a
bundling feature that I can no longer use. It would be very nice to be
able to do this, but honestly it is worth the performance hit to me.

Any large application needs structure, and yes underscores can be used
but this is a pain typing out long names every time, and what's the
harm? If you want to use bundling or don't like namespaces then just
don't use them.

On Wed, 2007-12-05 at 20:08 +0100, Jochem Maas wrote:
> Stanislav Malyshev wrote:
> >> +1 for putting namespaces on the backburner and taking the time to
> >> get it 100% right ...
> > 
> > What's "100% right"? Any proposals (besides braces)?
> 
> I'll take a guess that you put alot of effort into the namespace 
> implementation,
> that's the only reason I can think of that your taking it all so personally 
> and
> being rather vitriol.
> 
> for the sake of your health take a step back and breath my friend. you are
> not the car you drive, the clothes you wear or the namespace implementation 
> you
> created :-)
> 
> > 
> >> apparently people keep 'flogging this horse to death' because they are
> >> not
> >> convinced by your wisdom with regard to this decision - they may be
> >> idiots (me included)
> > 
> > I never talked about "idiots". I know smart people can have different
> > opinions, and - oh horror! - some may have wrong or mistaken opinions
> > too, and that doesn't make them idiots. How about you?
> 
> it was a self effacing comment. I think it's safe to say that compared to
> most of the php devs, I, and people like me could be considered idiots at
> least as far as developing is concerned .. it's all relative besides which
> the key words were "may be".
> 
> > 
> >> actually that is not true - a halfbaked concept is pretty much
> >> garanteed to give you
> >> and the users of your product more headaches than no implementation at
> >> all. and
> > 
> > This concept, however, is not "halfbaked".
> 
> based on the reactions it has been recieving I would disagree. that is not to 
> say
> that completing the baking process would not result in a wonderful functional 
> addition
> to the language. I'm just advocating putting it on the backburner until the 
> cooking
> time is complete.
> 
> "halfbaked" is probably the wrong word - it has negative conatations that I 
> didn't
> mean to imply.
> 
> > 
> >> besides possibly having to type a little less, there seems to be
> >> nothing namespaces would
> >> give us [in it's current form] that we cannot achieve already ... with
> >> the bonus that
> > 
> > Yes there is. More structured and clean code.
> 
> you have metrics to back that up? of course not because it's a completely 
> subjective
> point of view - and many people seem to think that there is no real gain in 
> this respect,
> besides there is nothing to stop me writing namespaced spaghetti.
> 
> I agree that namespaces pontentially offer a tool that allows developers to 
> create
> clearer structure in their code but given that it's only a potential why not 
> take a time
> out to hammer out more details, get more consensus and work out the details 
> of where
> namespacing should go in terms of functionality with the hassle of having to 
> worry about BC.
> 
> > 
> >> conversly - when namespace functionality is released, every developer
> >> will be confronted
> >> with any problems they might bring with them, at some stage, because
> >> there will be third
> >> party code out there that uses namespaces (code which for the sake of
> >> argument one would
> >> be required to use under some circumstances).
> > 
> > These problems being?
> 
> no longer having the option of bundling files for performance reasons is one 
> example, personally
> I have never done anything like that but apparently other people do and with 
> positive results for
> their applications - to me it seems that forcing such a restriction on these 
> people is against the
> pragmatic philosophy that [hopefully still] drives php, and is rather 
> artificial.
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to