SS_ Naming Convention

[Zenmonkey]

I'm wondering if naming Database classes with SS_ is solely reserverd for the framework of if it's safe to use elsewhere. I ran into an issue with where two modules used the class Color, one for data object, the other for a DBField. I figured the Database Field should be SS_Color, similar to SS_DateTIme

[Anselm Christophersen]

Relating to this, I’ve seen a namespaced table in our database.

Not sure if that’s intended/recommended/a good idea, and how it happened. But this could be a solution to your problem. See attached.

On 10 Feb 2016, at 22:26, Zenmonkey <ri...@nervedesigns.com> wrote:

I'm wondering if naming Database classes with SS_ is solely reserverd for the framework of if it's safe to use elsewhere. I ran into an issue with where two modules used the class Color, one for data object, the other for a DBField. I figured the Database Field should be SS_Color, similar to SS_DateTIme

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Loz Calver]

This is something that’s best resolved with the use of namespaces, as we’re trying to move away from SS_ prefixed class names. So for your example of class name collision the two fully-qualified class names might look something like:

ModuleAuthor\Model\Color

AnotherAuthor\Forms\Fields\Color

I’m not sure how well namespaced DataObjects currently work, but it’s something that’s on the agenda. There’s an RFC with a little more info here: https://github.com/silverstripe/silverstripe-framework/issues/4562.

[Loz Calver]

Oops, I mis-read DBField as FormField! A little work has already been done on namespacing DBField classes (as part of the PHP 7 compatibility work here). Contradicting my last post - DBField classes will probably have a 'DB' prefix. However, prefixing class names isn’t something that we’re likely to use anywhere else - we needed to prefix them with something because class names like Float are not valid in PHP 7.

[Zauberfisch]

Hey,

namespace support indeed exists, but it is currently _horrible_ in terms
of convenience. Yes, Database/DataObject support works. But namespaces
still break a lot of the SilverStripe magic such as SSViewer, parts of
routing, ...

I have tested the use of name spaces in 3.1 for a while and have
actually reverted all projects back to non-namespace code because there
where just to many issues you have to work around to use them.

I also dislike the SS_ prefix and would prefer to use namespaces, but I
don't see a full switch to namespaces happening anytime soon. There are
still to many things to do before that.


To answer the original question: no, it is not a good idea to prefix
with SS_ in your module.
If your module is minimalistic or does not use certain SS features, then
perhaps you can already use namespaces (simon_w has done that successfully).
If your module is like most others, for now I would recommend prefixing
them with a string in each class name.
so eg: "class MymoduleColor extends DataObject"


<^(((-<

> --
> You received this message because you are subscribed to the Google
> Groups "SilverStripe Core Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to silverstripe-d...@googlegroups.com

> <mailto:silverstripe-d...@googlegroups.com>.

> To post to this group, send email to silverst...@googlegroups.com

> <mailto:silverst...@googlegroups.com>.