Currently our coding conventions have major prohibitions on the use of
isset() and empty(). I can understand isset(), because sometimes it makes
more sense logically to have boolean casting or strict type checking, but
in the case of empty(), it's significantly faster than boolean casting and
is more readable.
If you're checking for *whether an array is empty*, which is more intuitive:
if( !$array ) // If the boolean value of the array is false
if( empty( $array ) ) // If the array is empty
Functionally, they're almost equivalent, as any value that evaluates as
false will also be treated as empty. The sole difference is 1) empty()
first checks if the variable is set and 2) empty() is faster.
I understand that there is a slight risk here due to empty()'s error
suppression, but in many cases it's obvious that a variable exists and it's
not necessary to sacrifice the logical readability of the code just because
a developer might make a typo and not realize it even though the same
variable is on the line above.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
---------- Forwarded message ----------
From: Brad Jorsch <bjorsch(a)wikimedia.org>
Date: Tue, Feb 5, 2013 at 5:43 PM
Subject: Re: [Gerrit] API PageSet allows generator for non-query modules -
change (mediawiki/core[master])
To: tylerromeo(a)gmail.com
On Tue, Feb 5, 2013 at 5:03 PM, Parent5446 (Code Review)
<gerrit(a)wikimedia.org> wrote:
> Yeah, I see the page, but it doesn't tell me anything interesting. The
only disadvantage of using empty() is for the off chance that you mispell a
variable name and the error is hidden, but it's obviously not the case
here. And in terms of readability, it makes a lot more sense to have if(
empty())
Then perhaps you should raise the question of changing the coding
standards on
https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP
Until then, let's not use empty() unless we explicitly want the "isset"
check.
---------- Forwarded message ----------
From: Jon Robson <jdlrobson(a)gmail.com>
Date: Mon, Feb 11, 2013 at 2:44 PM
Subject: Watchlists are coming to mobile
To: mobile-l <mobile-l(a)lists.wikimedia.org>, Wikimedia Mailing List
<wikimedia-l(a)lists.wikimedia.org>
After a few months of development the mobile team is launching
watchlists to the mobile site tomorrow. The feature to start with will
give a simplified recent changes view a la the desktop site as well as
a reading list view for users who are simply interested in keeping
track of articles they are interested in reading.
This change also brings in login and account creation functionality to
all Wiki* projects.
This from my perspective is one of the most exciting mobile
developments so far as it makes the watchlist star a much more
prominent figure in the user interface and will hopefully encourage
new users to create accounts to use it, many of whom may be unaware
that Wikipedia can be edited. The hope is these new users will find
the feature useful and can be lured into the realm of becoming a
contributor to our projects via mobile.
Provided we don't run into any issues during deployment this should be
deployed tomorrow.
Please feel free to comment on this mail but if you experience any
bugs in the aftermath please raise them here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
You can also try out the new feature a little early by opting into the
beta here:
https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions
Looking forward to all your feedback.
Screenshot:
http://imgur.com/jnl5XA4
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
Google's announced that they will run Google Summer of Code again this
year, and we plan to apply. I've updated
https://www.mediawiki.org/wiki/Summer_of_Code_2013 and I'd love for
potential mentors to add their ideas to
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects .
Note that this year students are expected to work on their project June
17-September 23, so mentors would also be needed during that period, and
somewhat less April 8th-June 17th for talking with potential candidates
and helping with the community bonding period.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hey everyone,
There was a brief discussion on this list on the subject of Composer use
in MediaWiki last October [1]. I also answered various questions
regarding Composer in a tech chat via Google Hangout in November. I
never responded to the mailing list thread and thought I'd bring up a
few points regarding the statements made then.
Composer is for the most part a library handling package metadata,
package repository metadata, version matching, dependency resolution,
downloading and unpacking packages as well as the processes that put all
of these parts together in an extensible way.
Composer originated from the ideas of a new plugin system for phpBB as
well as an installer for Symfony2 bundles, which we realized was really
a generic problem, so Composer has no direct ties to either of these.
However it was designed with these use cases in mind. More specifically
that means that while Composer comes with a nice default command line
interface, it is also very well suited for creating project-specific
package management tools on top of it, including web based ones if that
is of any interest.
There are multiple mechanisms in Composer which allow customization
while keeping the standard command line interface. Most notably custom
installers [2] which allow packages of a particular type to be installed
using custom installation code which allows one to modify pretty much
everything, and scripts [3] which provide ways of triggering either PHP
code or external programs based on various installation/update/removal
events.
If this alone is not enough for MediaWiki, you can simply use Composer
as a library saving you a lot of work when building a custom extension
management tool.
I'm happy to answer further questions, and you'll reach plenty of people
with composer experience on #composer and #composer-dev on FreeNode, too.
Cheers,
Nils
[1]
http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/thread.html#64…
[2] http://getcomposer.org/doc/articles/custom-installers.md
[3] http://getcomposer.org/doc/articles/scripts.md
Hi everyone,
Wikimedia Nederland invites all developers to the Amsterdam Hackathon 2013.
The hackathon is an opportunity for all Wikimedia community developers
and sysadmins to come together, squash bugs and write great new features
& tools. Unlike the previous years (2012, 2011, etc.) this Hackathon
won't be in Berlin, but in Amsterdam.
The event is open to a wide range of developers. We welcome both
seasoned and new developers as well as people working on MediaWiki,
tools, pywikiedia, gadgets, extensions, templates … .
It takes place from 24-26 May. If you’d like to attend, please save the
date!
There will not be an entrance fee for the event itself, but a
registration is mandatory. There will be a limited number of
scholarships available, details to be provided ASAP. We're currently
finalizing the arrangements of the venue. When we're done with that
we'll open registration.
Keep an eye on https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013
for updates!
Check this page for updates!
Maarten
Ps. Please spread the word
Hi, in the past we have been discussing the need to update
http://www.mediawiki.org/wiki/Developer_hub
Here is a basic proposal to get started. If we agree on the main idea
the implementation will be easier. Perhaps we can do it edit by edit
during some weeks, instead of an ambitious full rewrite:
http://www.mediawiki.org/wiki/Talk:Developer_hub#Developer_Hub_update
Once we are done with this we will decide whether something needs to be
done about https://meta.wikimedia.org/wiki/Wikimedia_developer_hub or
not. My personal opinion today is that it is simpler and better to have
all software development info under mediawiki.org - and referenced
through a one and only Developer Hub. But I'm open to be convinced with
better arguments. :)
PS: next week I'm on not-Xmas holidays, quite offline. Looking forward
to seeing more thoughts and offers to help by Feb 18.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil