Addon Namespace Prefix

64 views
Skip to first unread message

Christopher Pitt

unread,
Feb 17, 2016, 9:41:38 PM2/17/16
to SilverStripe Core Development
Hello!

Cam and I have been thinking about what to do with addons and the move to namespaces (with SS 4.0). We think something like "SilverStripe\Addon\" would make a nice namespace prefix, and help to keep the main "SilverStripe\" namespace open for CMS and Framework. Here's an example of that in action: https://github.com/sminnee/silverstripe-intercom/pull/10. Keen to hear errybody's thoughts on this...

Kind regards
Chris

David Alexander

unread,
Feb 17, 2016, 9:46:59 PM2/17/16
to silverst...@googlegroups.com
Hi Chris.

I like it!

Might you want to somehow distinguish between SS supported Addons and unsupported ones ? What about out deprecated/abandoned ones ? Just a thought.

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

Patrick Nelson

unread,
Feb 17, 2016, 9:49:10 PM2/17/16
to silverst...@googlegroups.com
Wait, what's an add on? Is that like an extension? Or a new name with the same (or slightly different) functionality? These are built by third parties, right? Or are they built by SilverStripe? I think the root namespace should be the actual vendor that's responsible for creating it. But I could be so sooooo totally off base here, so ignore me if I am :)

Christopher Pitt

unread,
Feb 17, 2016, 10:27:13 PM2/17/16
to SilverStripe Core Development
@david: talking specifically about supported modules here. Third-part modules should still be in their own vendor prefix.

@patrick: addon, module, extension etc. 

Stevie Mayhew

unread,
Feb 17, 2016, 11:36:09 PM2/17/16
to SilverStripe Core Development
I don't see a need for it? I imagine that the framework namespace will be `SilverStripe\Framework` and CMS `SilverStripe\CMS` (and so on) - not `SilverStripe`. If this isn't the case, then I am really confused about why they are separate packages. 

If you are writing an addon called `Framework` then its well, interesting, but probably a bad name for your addon.

Loz Calver

unread,
Feb 18, 2016, 6:01:08 AM2/18/16
to SilverStripe Core Development
What do you guys see as the benefits of this?

Class name collisions in modules are rare, even more so amongst the modules that this would be targeting (those that would be under the SilverStripe\ vendor namespace). I’m struggling to think of how we might encounter a class name collision - the only examples I can think of would be competing modules, but those would be under different vendor namespaces. If we’ve got a SilverStripe\ module that’s got the same FQCN as a core framework/cms class then that’s probably a sign that one of them is named incorrectly or should be in a different sub-namespace.

If it’s just about verbosity or clarity about what’s “core” and what’s not, then it’d probably be more useful to include the module name instead (e.g. SilverStripe\Blog\Foo).

Are there any other projects out there we can take inspiration from for this sort of thing?

Loz

Uncle Cheese

unread,
Feb 18, 2016, 3:47:00 PM2/18/16
to SilverStripe Core Development
Yeah, I'm not sure I see the benefit in this. I think the last thing we need is to create more obstructions to people creating and promoting modules, and, while I agree that we need a base level of conventions that a module should follow, this one feels a bit arbitrary to me, and I have a high level of confidence that a convention will naturally evolve.

As a parallel, I look at the way Composer packages have evolved. It's pretty much standard fare that packages are named [vendor-name]/silverstripe-[module-name]. It's not always the case, but enough so that it's workable. That came about naturally, and we didn't have to impose it. I think the less we impose, the more people will want to contribute.

Ingo Schommer

unread,
Feb 18, 2016, 4:01:15 PM2/18/16
to silverst...@googlegroups.com
Agree that it feels a bit arbitrary - the concept of "SilverStripe core" will become more fluent over time as we separate out things into modules (e.g. assets in 4.0).

Just a few examples of namespaces which feel natural to me without this SilverStripe/Addons classification:
SilverStripe/Model/DataObject, SilverStripe/Cms/SiteTree, SilverStripe/Blog/BlogEntry, SilverStripe/TagField/TagField, UncleCheese/KickAssets/KickAssetAdmin.

Note that there's an existing RFC for Namespacing which states: "However, the principle that we're not putting everything into SilverStripe\Framework is what should be agreed now."

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



--
Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

Christopher Pitt

unread,
Feb 18, 2016, 11:03:43 PM2/18/16
to SilverStripe Core Development
Ok, let's consider the matter settled then. Thank you for your feedback(s).
Reply all
Reply to author
Forward
0 new messages