(Doh, this mssage should've been here a bit earlier, sent from the
wrong email address. Some of the mentioned points have already been
discussed since).
For reference, here's a previous discussion on this topic?
http://groups.google.com/group/silverstripe-dev/browse_thread/thread/62069368c1a3d4df/9f9152e77060c394?lnk=gst&q=namespace
On 1/10/2009, at 9:23 PM, Andrew Short wrote:
>
> Hey All,
>
> I'm currently creating a class as part of the nestedurls branch -
> however due to it's possibly conflicting name I will be namespacing it
> in order to avoid problems such as that mentioned in issue #2827.
> Indeed, I think it is a good idea to namespace several core classes
> which are likely to conflict, either due to code from the PHP core/
> extensions or from other frameworks. Classes such as Session,
> Controller and Int are a few I can think of off the top of my head
> that, in my opinion, are likely to conflict.
I think its mainly a timing issue, as we can namespace properly
in 5.3. Now, can we live with potential naming conflicts
until 5.3 is a minimum requirement? Not sure, its still a long
way to broad 5.3 support...
>
> However, the current practice of namespacing core classes with "SS"
> when a conflict found should in my opinion be changed to proactively
> namespacing commonly named classes with an "SS_" prefix,
Agreed, the underscore makes it easier to read.
> * I think we should proactively namespace common class names in order
> to prevent issues recurring in the future, as well as easing
> interoperability between sapphire and other scripts/components.
I'm particularly worried about thirdparty modules using
very generic names that are likely to clash.
>
> However, the main problem with changing namespace separator and adding
> namespaces is backwards compatibility - we would have to rename
> SSDatetime to SS_Datetime for consistency, and I would recommend
> namespacing most of the DB field types due to their common names.
I'm not really a fan of "namespacing most classes",
we have to stay consistent. I know we're already violating
that with SSDatetime, but that was an urgent exception which
would conflict with every PHP 5.2 installation out there.
> In order to address this, I have created a very basic prototype of a
> refactoring script that can replace references to any namespaced
> classes - and as such I would recommend that as part of 2.4 we
> identify and namespace potential problems, as well as distribute a
> separate CLI (or web based task) utility to rename namespaced classes,
> in order to ease the transition for people upgrading to 2.4.
Good idea, we've got a lot of code to migrate.
One of the major downsides is that we lose backwards compatibility
for modules, we'd have to maintain two release branches for each
of them for a while (2.3 and 2.4 compatible). The switch to ANSI SQL
quoting makes this a pain already, so it might actually be good
to do in the same go.
Andrew, in case we decide to go this way, how much development
help can you provide? I think part of the reason we didnt do this in
the
past is that its basically a high impact distraction from actually
building stuff ;)
Ingo