I agree that loads of if's in code is not desirable. However, is there a
build time way of doing this?
At my time at Nokia, we had an absolute nightmare time with phone
variants. There are dozens for each carrier and country. Same problem.
You don't want your runtime cluttered up with "If a US AT&T do this, if
a German Vodafone do this" etc.
The solution was to have the packge build system generate the final
packages by parsing #ifdefs in the code. Each variant only then
contained it's specific blocks of #ifdef code. The even manage to
achieve the same approach with the java build system.
Is the git/PHP build system capable of doing something similar? This
would also go some way to solving your problem of creating definitive
tarballs for each version of MW.
On 25/02/13 23:59, James HK wrote:
>>> Just to clarify: are you saying that the need to support older versions of MediaWiki, and specifically 1.19, makes certain features in SMW impossible?
> I'm not saying it is impossible but as soon as you start using "if"
> statements to accommodate releases you introduce dependencies which
> will invite bugs to appear because the underlying method that is
> executed can act differently depending on the "if" release used.
>>> adding them more difficult, because of the need to add in a bunch of "if" statement
> I would say, release dependant "if" statements are always a bad design
> choice and should be avoided at all costs (see above, you can't
> predict a methods outcome due to an exogenous variable (namely an
> introduced release dependency)).
> PS: For example (it could be worst but haven't found any other
> example) which only carries a minor incision in how to get to the page
> content but it is still an "if" statement too many and bloating the
> code from its core purpose.
>  https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SemanticMediaWiki.git;a=blob;f=includes/queryprinters/FeedResultPrinter.php#l259
> On 2/26/13, Yaron Koren <yaron@...> wrote:
>> Hi James,
>> Just to clarify: are you saying that the need to support older versions of
>> MediaWiki, and specifically 1.19, makes certain features in SMW impossible?
>> Or are you saying that it just makes adding them more difficult, because of
>> the need to add in a bunch of "if" statements and the like? That's actually
>> a big distinction - I wanted to make sure I understood.
>> On Mon, Feb 25, 2013 at 6:04 PM, James HK
>>>> SMW 1.9 (15/03/2013) -> MW 1.19 (09/02/2012): 1.1 years
>>> On a site note, in two or three occasions when I was adding something
>>> to SMW 1.9 I had to back down because suddenly the approach preferred
>>> didn't work in MW 1.19 (I think it is one hook, two methods when
>>> testing against MW 1.19) which means I had to find a workaround just
>>> to make sure it works with MW 1.19.
>>> This sort of thing drains motivation (at least mine) while doing a
>>> change having the need to dance around a few more blocks just to
>>> satisfy the need of supporting MW 1.19.
>>>> SMW 1.10 (15/08/2013) -> MW 1.19 (09/02/2012): 1.5 years
>>> This proposal would take developers hostage to accommodate MW 1.19 and
>>> negate any possibility to use new classes introduced in MW 1.21
>>> (prominently Content class etc.).
>>>> They should also think about if a bug or feature is important enough to
>>> be backported.
>>> Well, if I find something to fix I'll do it for the current master and
>>> anyone who finds the time can make a backport but I'll stopped doing
>>> extra interventions some time ago. This also means that when SMW 1.10
>>> is in master fixes are applied to that master and any other branch has
>>> to find a maintainer if he/she wants to have those fixes applied.
>>> PS: When I started this thread, I thought I ask some tangible
>>> questions about how and why .. but somehow I have the feeling this
>>> discussion is going to be less tangible in its outcome because it is
>>> more about SemanticBundle or SemanticForms than it is about SMW and
>>> LTS. Of course if the discussion is shifting in favour of
>>> SemanticBundle being the main LTS release holder than this is fine as
>>> well but than we should shift the topic as well.
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> Semediawiki-devel mailing list
>> WikiWorks · MediaWiki Consulting · http://wikiworks.com
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> Semediawiki-devel mailing list