Zend weakness

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Though much of the post was OT here are some thoughts:

- I don't see how PEAR having a library feel, redundant classes, Zend's peer review, you not needing MVC (ZF does not require it), or when MVC makes sense have anything to do with class/file naming.
- I think you mean "low coupling" not "loose coupling" which is a data interchange term.
- I don't think exposing directory structure to the "client" (whatever that means) is more or less useful to any developer.
- The number one rule of OOD is not Open/Close. It is a good guideline, but composition is favored over extension these days. The idea that "you should never need to modify your class API *ever*" is completely unrealistic in my view.
- I don't think that changing interfaces is related necessarily means fragility, and by you definition it is only actual side effects that are a "problem."
- While class name are part of that interface contract, they are a trivially changable part -- as opposed to parameters and methods for example. Though I agree with your reason to avoid statics.
- Class name changes will not "reverberate throughout your source tree" because name changing is easy. And if you move a file and rename it in other systems you will have the same amount of work.
- You example of "Zend_Security_Libs_Crypt_Md5" is just opinion as to whether the information in the name is useful or useless -- it does convey meaning and I don't see how the same organizational information in not useful both places.
- It is easy to throw out a list like Fragility, Rigidity, Immobility, and Viscosity. I do not believe that naming/renaming is anywhere near a key cause of Fragility and Rigidity (again like methods/parameters). Regarding Immobility, it seems that the uniqueness of PEAR style names would improve reuse. Regarding Viscosity, PEAR naming would probably support keeping additions within the design better than other schemes. Nor do I see how any of those concepts has to do with "rot".
- Not sure how "include path's are not part of the component contract" makes sense here, especially because you are comparing compiled and linked languages to PHP which uses the run-time include() concept, which is different than even packages. PEAR naming is a solution to a problem that does not exist in the example languages you mention.
- Repeating "There should be no hardened relationship between source code and source tree does not make is so. The naming is part of the interface, but again is not anywhere near like changing parameters or methods when it comes to low coupling. Changing names requires search/replace; changing methods or parameters requires recoding.
- You say "but not everyone has a IDE that powerful." while saying that this is really an issue of large projects that would certainly use a powerful IDE.
- PEAR naming was designed to make "class names constructed on the fly" easier in PHP -- a class cannot be instantiated until included -- that's the point of the connection between the class and the file path.
- One of the reasons that Zend used PEAR naming is that it has proved to "to appeal to the widest audience possible."
- include() is not most typically hardcoded in PHP frameworks and class loading is an integral part of them. Comparisons to compiled langauges is not really pertinent.
- In my experience source trees are not that volatile and public interfaces do sometimes change.
- PEAR naming, because if it uniqueness supports "having a component which "drops" right into your application and you never have to worry about it again." That is another reason why Zend chose that style naming. You only need to look at their growing component library to see this.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

How? The directory naming is itself based on the class name and general grouping - the naming is not dependent on the filesystem, it's the opposite.
Huh, you lost me there amigo...

The file structure has a 1:1 relationship with class names, according to convention...regardless of who models what...whether the class names are declared first which then drive file structure or the file structure is created first then class names mapped to them, the point is, there is still a 1:1 relationship between class names and file structures...which is the bad thing...not what tells what to do what, which is what I understood you to be getting at :? 8O :lol:
I don't care where a class is located, so long as my code will always be capable of including it and it has a decent name
Bingo!!! You nailed it ;)

That tight coupling however, makes modifying your directory structure next to impossible. Organization on all levels of software development (source tree, source code, management, etc) is the impetus of good software design. A monolithic file structure is just as messy as a monolithic function which does everything and throws in the kitchen sink to boot.

If you cannot see how a clean, clear and well organized file structure is of upmost importance for project longevity and cannot see how and why a file structure can and will likely change (aka it's volatile) I seriously suggest you work harder at working on large projects. Yes it's true that volatility might become more stable over time, but the fact is, file structures should change over time. if they don't it's likely because your application is fragile and will break if something changes.

Changing the include path is absolutely required whenever a file structure is refactored. Regardless of whether you use a traditional naming scheme like Linux or a so-called user friendly naming scheme like Zend or PEAR. However only when there is a 1:1 mapping between class names and file structure does refactoring the source tree break the golden rule of OOD:

I'll repeat:
OCP (Open-Close Principle) states an component should be open to extension but closed for modification
Refactoring your source code and having to change class names because a source tree was refactored breaks this rule. This rule does not apply to refactoring source code when all your changing is include paths as an include path IS NOT part of a components interface or contract. So despite the fact, that you could argue that a class name change would require only ONE more change than just changing the include path, the fact remains, changing the class name breaks the contract.

I don't know how much more clear I can make that. :roll:

It might at first seem like a trivial matter to search and replace a single include path and a single class name with the updated version, but given my examples of runtime class instantaition, you should be able to see why this is a potential problem.

Again, my suggested method doesn't break OCP. As the include path is *NOT* part of a component's interface or contract. So as practical as Zend may seem and possibly be in trivial situations, it still breaks a rule of OOD.
The PEAR naming convention has been in place for years and has had no serious issues I know of.
Fine, fare enough, but software has been developed for years and year without MVC or other best practices and you seem to accept those for what they are.

Best practice does not nessecarily mean "Absolutely only way to do business" they are guide lines which in theory make development better on the whole.
No, but a classname should make immediate sense
Agreed.
When I see Zend_Http_Response, I immediately know what I'm dealing with. It's blatantly obvious from the descriptive naming convention. That it is reflected in the directory structure is an added bonus
Agreed and bzzzt...again...the fact it's reflected in the directory structure only means that two entirely different levels of software development organization are now tightly coupled. You can have Zend_Http_Response but no where does it make sense to have that bound to a directory: /Zend/Http/Response

That cohesion, like in most other cases is a bad thing. This simply hasn't been documented as I do believe my arguments to be unique, thus I think your finding my arguments hard to swallow.
and since when is it that modifying open source code is supposed to be made difficult
Now your putting words in my mouth...which clearly suggests to me you *don't* understand the topic at hand...

No where did I say open source software isn't to be easily updated or modified...I said a component interface is a contract which should not be broken - this is a existing rule look it up ;)

By moving the class you need to also move directories. Regardless of which one causes the other to move, the tight coupling causes one to force an effect of fragility onto the other. I'm not saying you cannot open your favourite IDE and look into the Zend source code, in fact I suggest doing otherwise as it's the best way to get insight into how things tick. What I am advocating is that a client should never have to update any of their code (more specifically a component interface or contract) because a change has occured in the framework source.

Remember what I said earlier about how an include() IS NOT part of a component interface before you start calling me a hypocrite ;)
A client has other ways of finding file locations for alternatives.
Exactly, so why not use em' atleast they don't break any OOD principles... :P
I would assume the filesystem has little deliberate impact on class naming. Maybe in a more complex design, but the ZF's shallow class hierachy limits such.
I agree, however in my experience sometimes looking at the over all file structure and overall class hierarchy can sometimes lead to better more organzied code for both parties. Zend's shallow class hierarchy is the only thing that saves it but may also hinder it's future.

They cannot refactor Zend_Http_Response into something like Zend_Http_Server_Response because that would break anyones code (atleast according to OOD principles) which relied on Zend_Http_Response as they would have to find all references to Zend_Http_Response and rename them (breaking the component interface) to Zend_Http_Server_Response.

Nevermind that it's only one more change as compared to having to change only the include() path...the fact is...include path() is NOT part of a component interface or contract. Besides I have demonstrated possible scenerios where that "one more change" rule doesn't apply.
Can you actually name any project that has *never* changed a single class interface? I can't. Not saying they don't exist, but I would suspect they're far being a majority...
LOL...sorry but you clearly just made it obvious your relatively new to programming or atleast haven't experienced much outside of PHP. Application API changes like crazy, but only because version one is typically much different than version two. Frameworks, which are a completely different thing...the API in most professional frameworks I would imagine is fairly rock solid once released.

It is of no coincidence that *every* major framework that has almost ever existed still today follows an almost identical API as it did when they were first released. When I started programming Windows applications under Windows 3.1 (using VB3) I started learning about the Windows 16/32 API...there is a function called CreateWindow() which even under XP still exists and is still used in current day development. It also has a extended function called CreateWindowEx which was introduced in win32 I believe to allow Windows to take advantage of new 95 styles.

You can still take a Windows 3.1 application source and compile it under Windows XP and likely even Vista. Vista because of the large paradigm change from 32 to 64 bit support, etc...may suggest using an alternative function API, but I bet you still can get away with it Windows 3.1 calls.

MFC source code from version 5.0 will compile under Visual Studio 7 and likely 8, albeit not without a tons of compiler errors (C++ specific not the framework). Still I'm willing to bet it will compile. ;)

Has MFC undergone substantial changes in the source tree over the years, I imagine it's change somewhat...does that cause code written for MFC version 4 or 5 to "break" under version 7 or whatever?

Yes it probably breaks, but not for the reasons I have marked above...rather TYPE differences, missing libraries, etc...and yes you will likley have to adjust a few includes() but it's not breaking any OOD principles...

Cheers :)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

I think you mean "low coupling" not "loose coupling" which is a data interchange term.
Yes you are correct.
I don't think exposing directory structure to the "client" (whatever that means) is more or less useful to any developer
I agree. They are of little practical use, seeing how include dependancies are automatically generated by documentation software anyways.
The number one rule of OOD is not Open/Close. It is a good guideline, but composition is favored over extension these days.
First off, no where in that principle does it state exactly that extension means derivation. Composition cannot not favoured (today anyways) as they serve very different purposes.

is_a and has_a to me personally...although they both suggest adding to an object or extending it...are very different things ;)
the idea that "you should never need to modify your class API *ever*" is completely unrealistic in my view.
Then, like I did Maurgrim...I have to inform you...that you need more experience...

Again, your lack of experience in working with frameworks, libraries, etc...as you can search for yourself...Windows API has been fairly static over the last, oh I dunno...10-15 years...Changing an API is acceptable in an application, but completely retarded in a framework or library. I can't believe you just said that...

Volatile framework or library API...Think about it...

Your writing a PHP application...and you rely on all the array_* functions...then one day in Version 6.0 PHP no longer array_* functions...they have vector_* functions....

Your code would be screwed to peices...it's the driving force behind PHP persisting such a obviously poor naming convention in it's codebase...why???

BECAUSE...changing a library API is worse than a bad naming scheme...and code clarity (which includes consistency) is very important...you can see how important it MUST be if PHP hasn't updated it's API.
Though I agree with your reason to avoid statics.
I never said avoid statics...I said they add to the problem of multiple class names existing in a source tree instead of just one in the case of object creation...
And if you move a file and rename it in other systems you will have the same amount of work.
No you won't...potentially...not even close...again...you seriously need to work on a larger project I think inorder to see what it is that I am saying.
ot sure how "include path's are not part of the component contract"
I'll read the rest of the post, but this is my last reply...as clearly you are not understanding what it is that I am saying...

Cheers :)

p.s-Thanks for the feedback.

p.s.s-What languages do you "honestly" have real experience in? I assume PHP, but what else...

I think you might say Java, so I ask, can you show me real proof that Java API from version until now has changed? Remember I mean contract not new functions added to derived objects...

Show me a single instance in a real project (not one your working on in your spare time) which used a library with a volatile API. :lol: Not even PHP API has changed...and it seriously needs re-working as the inconsitencies like array_filter and addslashes are clearly using different naming conventions...and are ripe for a slight refactoring...
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:I'll read the rest of the post, but this is my last reply...as clearly you are not understanding what it is that I am saying...
I am simply disagreeing with you. I plan to no longer enter into discussions with you because of you continued personal attacks.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

LOL...sorry but you clearly just made it obvious your relatively new to programming or atleast haven't experienced much outside of PHP. Application API changes like crazy, but only because version one is typically much different than version two. Frameworks, which are a completely different thing...the API in most professional frameworks I would imagine is fairly rock solid once released.
Sorry to burst your bubble but I've been programming for nigh on 13 years...C, C++, Java, PHP and Perl and others. PHP is largely a hobby of mine (I'm a self confessed PHP Hobbyist). It's not my primary programming language. I *fully* understand what you are saying. But please keep your assumptions to yourself - it's more effective to hit a person's statements head on with a conflicting piece of evidence than to accompany your evidence with a blatantly false personal assumption...;).

You clearly stated:
3) The number one rule of OOD is likely the OCP: An object/component should be open to extension but closed for modification. This means, you should never need to modify your class API *ever*
I replied:
Can you actually name any project that has *never* changed a single class interface? I can't. Not saying they don't exist, but I would suspect they're far being a majority...
Neither quote was qualified by reference to a "framework". You stated a general principle, I stated a counter argument. If you wish to qualify this to a specific circumstance then do so - just don't add the qualification after and then assume I'm psychic...:roll: Furthermore I *did* qualify mine! I said they existed - but in terms of the number of projects (not just frameworks) were a minority. Is this false? What's the ratio of Applications using the WinAPI to the Windows API itself? But if we do add a framework condition...

You seem to agree!
It is of no coincidence that *every* major framework that has almost ever existed still today follows an almost identical API as it did when they were first released.
Almost identical API? Wait, you mean they changed it? Which API would this exception be? Or could be all of them perhaps.

If we remain on-topic, API changes generally follow a pattern specific to the developer's required level of compatibility between iterations. For large extremely popular APIs, this is basically "break nothing". This is *not* always the case however. JavaAPI for example has been broken - I'm not a wizard with Java5 but 1.4 contained some breaks as I recall.

I would suggest API's in many cases evolve. It's even a desireable trait since having to constantly refactor around new functionality and maintain backwards compatibility past a certain point starts adding more complexity and leads to bloated code. I would add the contrast between Python and Java as an example.

My last comment is that I just disagree. :lol:
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:
Hockey wrote:I'll read the rest of the post, but this is my last reply...as clearly you are not understanding what it is that I am saying...
I am simply disagreeing with you. I plan to no longer enter into discussions with you because of you continued personal attacks.
Your right, after reading my post a day later, I see how I may have come across as condescending. However in all fareness many of your replies come across the same way. To suggest I was off topic in a thread that I started and probably (in all reality) have a better understanding of (seeing how I've likely spent more time thinking about this than you) was rather harsh don't you think?
Maurgrim wrote:Sorry to burst your bubble but I've been programming for nigh on 13 years...C, C++, Java, PHP and Perl and others. PHP is largely a hobby of mine (I'm a self confessed PHP Hobbyist). It's not my primary programming language. I *fully* understand what you are saying. But please keep your assumptions to yourself - it's more effective to hit a person's statements head on with a conflicting piece of evidence than to accompany your evidence with a blatantly false personal assumption.
Ok, but if you have such an established programming history, how can you say you don't know of any stable API? To me that just sounds foolish as I can likely find 100 library API which have remained stable for years...

Probably the most important rule to follow when developing software is code re-usability...a framework, library or SDK like the Windows API are all excellent examples (and there are thousands more) of API stability. They do not change, and for good reason....

I've listed two examples of a stable API and now I ask you to give me an example of an unstable API??? Before you go telling me anymore about "using conflicting evidence"... :?

I can't think of a single library where in version 1.0 they had an API function like:

Code: Select all

Zend_Config
and in the next version they had an API like:

Code: Select all

Zend_Something_Config
Any API, SDK, Library or Framework which did that would *not* be in business for very long...and yet you and Arborint both hinted at the fact that API stability is *not* that big an issue...when clearly it's the impetus behind software reusability. As I can't think of a better example of reusability then a framework, library, API or SDK...

So please show me an example...
Neither quote was qualified by reference to a "framework". You stated a general principle
Now your back peddling(sp?)... :P

What is this entire thread about? Your inhouse application or a "framework"??? What context did you think I was speaking under?
Furthermore I *did* qualify mine! I said they existed - but in terms of the number of projects (not just frameworks) were a minority. Is this false? What's the ratio of Applications using the WinAPI to the Windows API itself? But if we do add a framework condition...
Actually, you said:
Can you actually name any project that has *never* changed a single class interface? I can't. Not saying they don't exist, but I would suspect they're far being a majority...
And I replied by giving two examples of a API which has remained fairly rock solid for atleast a decade.

Windows success (as I would think most Windows developers would agree) is in it's API stability and minimal code changes required to port an application from 16 to 32 to 64 bit.
What's the ratio of Applications using the WinAPI to the Windows API itself? But if we do add a framework condition...
Pardon my confusion, but:

http://en.wikipedia.org/wiki/WinAPI

There exactly the same thing :P Incase you meant something else...can you elaborate? If you meant MFC over plain SDK API calls...the ratio is heavily in MFC's favour since verion 5 of MFC. Very few applications use straight SDK anymore, except little utilities where performance might be a issue (firewall type applications).
Almost identical API? Wait, you mean they changed it? Which API would this exception be? Or could be all of them perhaps.
Changed it? no because that would break the number one golden rule of a component being "open for extension but closed for modification" they extended it...

CreateWindow and CreateWindowEx are examples of a component having it's interface extended, but not changed. COM has extended many of it's interfaces (third example) for instance many interfaces have a ISomeInterface2 or ISomeInterface3, etc...

I should clarify that YES microsoft does occassionally depricate some API...IWebBrowser is a example...but from personal experience this is quite rare and not really a problem. Some planning of a component API will typically yield somewhat stable interfaces. It's the implementation that should change not the interface (a class name is part of the interface).
I would suggest API's in many cases evolve.
Yes they evolve by extension *not* by modification...

Again, Windows introduced CreateWindowEx (I believe in Win95) so applications could adjust their code to use the "extended" window creation API as opposed to the Windows 3 CreateWindow function and take advantage of new Windows styles, etc...

They *DID NOT* however change the function signature of the original CreateWindow() because obviously that would break any backwards compatability and minimize code reuse. Both very bad things in a API.
It's even a desireable trait since having to constantly refactor around new functionality and maintain backwards compatibility past a certain point starts adding more complexity and leads to bloated code. I would add the contrast between Python and Java as an example
I am not familiar with Python.

A stable API is important in either group (Framework or Application). However an application, by virtue of it's "vertical market" will obviously be more likely to have API unstability issues. A framework (which the context of this entire thread has been under) is not in the same categorey. I challenge you to give me proof of a library which has undergone significant API changes (whereby they drop a previous function signature in favour for an newer function signature, not extension like Windows examples I gave).

In making this *very* clear...I was speaking under the context of a framework...in that API stability is an important issue - we are both on even grounds and agree, correct? However where we disagree is in application API stability in that you feel code reuse on that level is not as important as I do?

Code reuse is a vague subject and can mean many different things to many people. Some people it might mean snippets of for loops, etc or quick and dirty copy/paste type code fragments, where as personally I refer to a entire component having the ability to be reused in many places. As a C++ zealot and OOP fanatic...object reusability is waaaaay more important to me that say if you came from a procedural background in C, where the idea of code reuse was usually function specific or library specific (more cut and paste in nature than OOP).

This is perhaps where we are all differing...I don't know...I can understand if your background was in procedural why you might be hardened in your ways in thinking. When I first transitioned from C SDK windows development to MFC Windows development, the idea of all the additional bloat didn't really appeal to me and it took me a good couple years to fully accept the advantages over code bloat and pure speed. So I've been there myself.

Perhaps, if your background is in Java and their API has been unstable...and maybe even for the reasons I mention above (academics you are allowed such flexibility - but Windows would not be as commercially successful as it is has been if the API was that unstable - I promise you this) again I could understand why making the transition might be difficult despite being a full blown OOP language.

IMO, the fact remains and I believe the examples/reasons I have given above demonstrate this...the Zend/PEAR naming scheme do break many OOD principles and good software design policies especially from an OOP perspective. I have a few other reasons why I dislike Zend, but those are neither here nor there, but I'll blog about them over time and your more then welcome to read and comment.
My last comment is that I just disagree.
I guess I have to just take a breathe and accept that then huh. :P In all honesty, I appreciate it as it makes me think twice and either re-asserts my own opinion or changes it for the better or possibly worse. In this case, I'll stand my ground as I feel I have substantiated my claims to the nines and have asked the opinion of well respected indutry professionals, whom seem to agree. :P

To re-iterate, both yours and arborints arguments are and were appreciated...I will use all your input to the best of my ability in shaping my own framework.

I apologize for any bad feelings I may have sent your way. ;)

Cheers :)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

I only skimmed the thread but this jumped out at me
2) A framework, has no need to expose the directory to a client via the class name.
That isn't entirely true. The framework itself doesn't need to expose the directory to a client, but when considering the application tied into the framework it would be very useful to know where the requested class can be found.

Code: Select all

$plugin = new Application_Plugin_Foobar();

//or

class IndexController extends Application_Controller { }
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post by n00b Saibot »

I would suggest you Hockey that you should try to choose your words carefully while posting. Somethings we say face-to-face doesn't come same way when said through text. text can't produce emotion.. remember that or you'll get yourself burnt soon :!:
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Jcart wrote:I only skimmed the thread but this jumped out at me
2) A framework, has no need to expose the directory to a client via the class name.
That isn't entirely true. The framework itself doesn't need to expose the directory to a client, but when considering the application tied into the framework it would be very useful to know where the requested class can be found.

Code: Select all

$plugin = new Application_Plugin_Foobar();

//or

class IndexController extends Application_Controller { }
Dude...there are counter arguments for everything...no matter how logical or illogical someones case may be...

Your missing my point...sure...it's helpful for a core developer to know where in a directory structure a certain class might lie, but IMHO there is little need for a client developer to ever need to know this...outside of just needing to include the file...in which case, they can look at the automagically generated docs and see where the file is stored so they can include that class in their application...why is it useful to have that information displayed in a class name??? What could does it do, but convolute things? It's redundant...do you think? Seeing how that information is already available in docs as most DocGens display include dependancies for you.

From a client perspective I cannot see the usefulness...even given your example...I'm missing something... :?

When writing an application, your concern shouldn't be where a class is located in a framework, it should be focused entirely on writing the bread and butter of your own application. I think we all can agree on that...can't we? So from a client perspective...aesthetically speaking...even though having a directory structure reflected in your class names does no harm...it's redundant as far as I can tell...

Can you elaborate further, as your argument was only detailed enough to confuse me :P

Cheers :)

Noob_sailboat??? Your right, I agree with you in that regard...but we're all human...and we all have emotions...and sometimes with some people...out emotions get the best of us...especially when we think we're right...I can only say a few of you have proven to me that you are exempt from this. Everah seems to always have a "double take" on things before answering or replying...but we all can't be Everah's can we? :P

I would love to think twice, but when I feel attacked it's in my nature to attack back...so I think this gate swings both ways...wouldn't you agree?

You don't ever see me ever attacking or criticizing d11 or Everah...do you? Why? Because they don't ever leave me with the impression they are arguing in a authorative manner...but rather, they argue in a suggestive or querying manner...there is a big difference and it seriously influences my response.

In anycase, I accept I was wrong in the way I replied, but I am not the only one guilty of this IMHO...but I have no problems being public enemy number one 8) so long as issues get brought up and resolved before something silly happens I've done my job and I'm happy :)

Cheers :)
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

there is a big difference and it seriously influences my response.
You're so easy to influence :lol:

Kidding. Sorry, just couldn't resist.... ;)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I apologize for any bad feelings I may have sent your way.
None here. I have thick skin. If it effects me on some deeper level I'll drink it off later...:).

I'm finished arguing at this point (otherwise we'll be at it forever). I scanned through the more recent postings again and like all long topics we evaded understanding each other's points at times. I'll concede WinAPI is a goog example of API stability. I would note this does not make WinAPI a better solution by default based on the general attitude I hear from others - I'm not a WinAPI user myself, I get irate around that level of memory management. Microsoft have done their own spots of API changing over recent years - VB.NET and .NET 1.1 spring to mind. Java while largely stable has had its minor changes between versions - Sun also recommends not using the deprecated methods/classes and updating legacy code in so far as practiceable. I guess its just my attitude - I expect changes and problems to crop up. Look what I have to look forward to: PHP6, Python3000, Java 6, and whatever else is creeping up...
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post by n00b Saibot »

Maugrim_The_Reaper wrote:I'll concede WinAPI is a goog example of API stability.
yeah its quite goog :lol:
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

^^^ :lol:

I think this thread needed some humor...but as far as I am concerned...it's done...and I think Maurgrim and Arborint are in the same boat...and I'm not really interested in having this popup in three months down the road again, so if any mods want to drop it from the face of the earth...you have my blessings :P

Cheers all, I'm going out for a night...
nameless1
Forum Newbie
Posts: 15
Joined: Sun Nov 05, 2006 1:14 pm

Post by nameless1 »

You might end up with class names so long they run you off the page (exaggerated).

Quote:
Zend_Application_SubSystem_Core_Module_Config_Status_Helper_Abstract


Personally, as descriptive as it is...ia way to long for me...2 maybe three and at absolute MOST 4 sections per namespace...

I am writing a framework and i have prefixed all my classes with my name

Charles_Config();
Charles_Template();

All of my classes with the odd exception are abstract so that i could separate the configuration for various reasons. some of my classes are abstract as i just wanted the data source to be abstract (in place of queries)

But The extended classes are called

Charles_Extended_Config();
Charles_Extended_Config();

based on what you said you would think this would be a problem but i have a class called Charles(); that ties it all together inside this class i have

public static Config();
and
public static Registry();
public static Template();

for example

that can be called via

Charles::Config();
Charles::Template();
Charles::Registry();

because I am adding most htings to the registry i can check if its alreayd in it and if it isnt i include the classes using

Charles::load_class($directory, $name);

if I don't want a singleton style affect I just store a boolean value of true in the registry so I know it has loaded the included files. The framework I am doing is not finished but i think this approach will work. Just remember to wrap your functions within an extra layer. And try to replace singletons with a registry where possible. So far my only singleton is inside my registry class. Before this framework I was over using singletons a lot as I did not have such a good way of sticking it all together.

There is the option of using an autoloader but its really not worth it when you can write a public static function to handle the required files the autoloader is to much hassle as it makes it harder to break the parts up at a later date.

(before i settled on this approach i considered autoload and i settled trying to iterate through the framework directory until it found the file its not a efficient way to do this and is not worth doing unless your framework is small and contained in one directory)
Post Reply