2.0 - Make the interfaces Standalone

83 views
Skip to first unread message

George Wilson

unread,
Sep 22, 2014, 12:41:54 AM9/22/14
to joomla-dev...@googlegroups.com
I'd like to see us make our interfaces into standalone repo's (similar to what Amy did with Molajo and https://github.com/CommonApi). This should make it easier for people to build in their own standalone features without having to download an entire repo.

Kind Regards,
George

Michael Babker

unread,
Sep 22, 2014, 8:15:22 AM9/22/14
to joomla-dev...@googlegroups.com
I'm not sure how I feel about this.  On the one hand, it makes it so that you're only dependent on an interface, but on the other hand now your dependencies include the entire Framework stack's interfaces.  I'm also not sure how I'd feel about \Joomla\Common\TransportInterface versus \Joomla\Http\TransportInterface (as an example); the latter more explicitly defines to what the interface is truly an interface for using just the class names.  This might be a moot point too, but until Symfony's packages go on a major diet, the download sizes of our repositories is really not that bad (1.x branches are pulling in the Tests and a couple extra things, but 2.0-dev is down to a handful of files in some cases).

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

George Wilson

unread,
Sep 22, 2014, 9:10:33 AM9/22/14
to joomla-dev...@googlegroups.com
I completely agree that for our packages it's less of an issue with size than others such as Symfony but I'd also consider it based on experience I've had in other areas good practice (e.g. thinking about using the symfony interfaces for session in the CMS or some of the guzzle interfaces in the http framework class) where I'd like to consider using the interfaces of these big packages so that other people can tap in and make alternative implementations that can just plug and play, but I just don't want a class sitting there doing nothing when I'm trying to use the interfaces. So I'd argue that it's just good practice anyhow to show as an example to others than as much of something that we HAVE to do.

And ya know that's a lot of why we have the interfaces, so people can plug and play. You don't need to have to use the entire stack interfaces. Again look at what Amy did - she just used a different name altogether. So you'd have

\JoomlaApi\Http\Transport interface

which again is more inline with me creating my own http component to plug and play than  downloading all the interfaces when all I want is the http specific stuff. 

Kind Regards,
George
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.

Nils Rückmann

unread,
Sep 24, 2014, 6:47:32 PM9/24/14
to joomla-dev...@googlegroups.com
Whats about interoperability ? By moving the interfaces you would need two packages for each "real package" like Joomla\Foobar and Joomla\Foobar-API.
I had similar ideas a while ago and decided that this is not a coding issue, but a documentation issue, which is why i'm using the conventions (PHP-FIG) to crawl the projects for interfaces only and using those as public docs.
Reply all
Reply to author
Forward
0 new messages