Re: Namespace

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. >