Re: [Wikitech-l] Wikitech-l Digest, Vol 58, Issue 40 - Wikitech-l

23 May 2008

      FUCK YOU
On Thu, May 22, 2008 at 5:17 PM, wikitech-l-request@lists.wikimedia.org
wrote:
...
Send Wikitech-l mailing list submissions to
       wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
       wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at
       wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:

Re: Wikitech-l Digest, Vol 58, Issue 39 (Azu)

Message: 1
Date: Thu, 22 May 2008 17:17:12 -1000
From: Azu azumao@gmail.com
Subject: Re: [Wikitech-l] Wikitech-l Digest, Vol 58, Issue 39
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222017n74896f17v8b3a837f8c3dfcd0@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
THIS IS YOUR LAST FUCKING WARNING IF YOU SEND ME ONE MORE FUCKING EMAIL I
WILL REPORT YOU TO YOUR ISP BITCH
On Thu, May 22, 2008 at 5:14 PM, wikitech-l-request@lists.wikimedia.org
wrote:
...
Send Wikitech-l mailing list submissions to
       wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
       wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at
       wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:

Re: Wikitech-l Digest, Vol 58, Issue 38 (Azu)

Message: 1
Date: Thu, 22 May 2008 17:14:43 -1000
From: Azu azumao@gmail.com
Subject: Re: [Wikitech-l] Wikitech-l Digest, Vol 58, Issue 38
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222014j28e22948j5580f1aa3a569245@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
I SAID STOP EMAILING ME MOTHERFUCKER
On Thu, May 22, 2008 at 5:13 PM, <wikitech-l-request@lists.wikimedia.org
wrote:
...
Send Wikitech-l mailing list submissions to
       wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
       wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at
       wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:

Re: Wikitech-l Digest, Vol 58, Issue 37 (Azu)
Re: PHP design basics (Edward Z. Yang)

Message: 1
Date: Thu, 22 May 2008 17:11:38 -1000
From: Azu azumao@gmail.com
Subject: Re: [Wikitech-l] Wikitech-l Digest, Vol 58, Issue 37
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222011u18cfa57ag57c297fe3fca9607@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
GO TO HELL AND GET FUCKED UP THE ASS YOU FUCKING PIECE OF SPAM
On Thu, May 22, 2008 at 5:09 PM, <
wikitech-l-request@lists.wikimedia.org
...
...
wrote:
...
Send Wikitech-l mailing list submissions to
       wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
       wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at
       wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:

Re: PHP design basics (Quasar Jarosz)
Re: Wikitech-l Digest, Vol 58, Issue 36 (Azu)
STOP IT!! (Azu)
STOP IT!!! (Azu)
STOP IT!!!!! (Azu)

...
...
...
Message: 1
Date: Thu, 22 May 2008 08:59:14 -0500
From: "Quasar Jarosz" quasar@ja.rosz.org
Subject: Re: [Wikitech-l] PHP design basics
To: "Wikimedia developers" wikitech-l@lists.wikimedia.org
Message-ID:
       79f4f780805220659v4abf90d7q963b4e954e29095f@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
...
== Objects are hashtables ==
Member variables can be added and removed dynamically. It is your
fundamental right as a PHP programmer to do this, nobody will ever
take
...
...
it
...
away from you.
Do you know of anywhere i can get some more information on this
behavior? I believe i have read every page of the PHP manual and I
had
...
...
...
no idea this behavior was possible!
Quasar

Message: 2
Date: Thu, 22 May 2008 17:08:37 -1000
From: Azu azumao@gmail.com
Subject: Re: [Wikitech-l] Wikitech-l Digest, Vol 58, Issue 36
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222008s75c83fc5k44a4d1f3ea9987ff@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
WHY THE FUCK WON'T YOU STOP FUCKING SPAMMING ME MOTHERFUCKER GO TO
HELL
...
...
AND
...
DIE
On Thu, May 22, 2008 at 4:51 PM, <
wikitech-l-request@lists.wikimedia.org
...
...
wrote:
...
Send Wikitech-l mailing list submissions to
       wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
       wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at
       wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:

Re: [MediaWiki-CVS] SVN:  [35156]
trunk/phase3/includes/filerepo (Brion Vibber)
Re: PHP design basics (Brion Vibber)
Re: PHP design basics (Chad)
Re: PHP design basics (Edward Z. Yang)
Re: So... status of category intersections? (Roan Kattouw)
Re: PHP design basics (Tim Starling)
Re: PHP design basics (Nick Jenkins)
Re: PHP design basics (Tim Starling)

...
...
...
Message: 1
Date: Thu, 22 May 2008 09:27:47 -0700
From: Brion Vibber brion@wikimedia.org
Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN:  [35156]
       trunk/phase3/includes/filerepo
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Message-ID: 48359F03.2050305@wikimedia.org
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Roan Kattouw wrote:
...
brion@svn.wikimedia.org schreef:
> * Asks server for mime type, but doesn't get it back yet
>
That's due to a typo:
>
> +
> +    function findFile( $title, $time = false ) {
> +            $info = $this->queryImage( array(
> +                    'titles' => 'Image:' . $title->getText(),
> +                    'prop' => 'imageinfo',
> +                    'iiprop' =>
'timestamp|user|comment|url|size|sha1|metadata|mimetype' ) );
...
>
There it is. You should use iiprop=mime, not iiprop=mimetype.
Ah, but I didn't get a mime back with my query with "mime" until I
fixed
...
...
the API's own typo -- it looked for "mimetype" but that didn't get
past
...
...
...
the input validation -- in r35185... :)
...
The rest of this stuff looks good. You seem to have fixed the
canonical
...
...
...
namespace thing. To what degree did you test/profile/benchmark
this?
...
...
...
Pretty much not profiled or benchmarked at all. :)
Just poking at it a bit on my test comp. I wouldn't recommend it
for
...
...
...
...
general use at the moment.

-- brion

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg1nwMACgkQwRnhpk1wk46e7QCgxIOcZZYOKQOT+tUpMbGYQxA1
bYcAn05gvvUa7WzBGVlOh/6s9uc+exYT
=mwZt
-----END PGP SIGNATURE-----

Message: 2
Date: Thu, 22 May 2008 10:00:03 -0700
From: Brion Vibber brion@wikimedia.org
Subject: Re: [Wikitech-l] PHP design basics
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Message-ID: 4835A693.90102@wikimedia.org
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
DanTMan wrote:
...
extensions/ExtensionName/ExtensionName.php:
$wgHooks['LanguageGetMagic'][] =
'ExtensionName::LanguageGetMagic';
...
...
...
...
...
$wgExtensionFunctions[] = array( 'ExtensionName',
'ExtensionFunction'
...
...
);
...
Oooh, avoid that last -- that'll load your class on every request,
whether it's needed or not.
$wgExtensionFunctions is for initialization functions which will
need
...
...
to
...
...
be run during Setup.php, after most of the basic infrastructure is
up.
...
...
...
These days there's actually usually little if any need for such
functions, since we've got the various hook arrays of all sorts
which
...
...
...
...
are designed for extensibility and lazy-loading; you can set your
various information directly in the arrays in your config/loader
code.
...
...
...

-- brion vibber (brion @ wikimedia.org)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg1ppMACgkQwRnhpk1wk45KkQCg2iSiouyAnhT7lYpdAmjkViVD
WywAoNZ77bk3rTPe+0KKzou3yYn9QpzD
=y7Nd
-----END PGP SIGNATURE-----

Message: 3
Date: Thu, 22 May 2008 13:43:36 -0400
From: Chad innocentkiller@gmail.com
Subject: Re: [Wikitech-l] PHP design basics
To: "Wikimedia developers" wikitech-l@lists.wikimedia.org
Message-ID:
       <5924f50a0805221043p4a19b3e9x7cbce95798278bf@mail.gmail.com
...
...
...
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 22, 2008 at 1:00 PM, Brion Vibber <brion@wikimedia.org
...
...
wrote:
...
...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
DanTMan wrote:
> extensions/ExtensionName/ExtensionName.php:
>
> $wgHooks['LanguageGetMagic'][] =
'ExtensionName::LanguageGetMagic';
...
...
...
...
> $wgExtensionFunctions[] = array( 'ExtensionName',
'ExtensionFunction'
...
);
...
...
Oooh, avoid that last -- that'll load your class on every
request,
...
...
...
...
...
whether it's needed or not.
$wgExtensionFunctions is for initialization functions which will
need
...
...
to
...
...
be run during Setup.php, after most of the basic infrastructure
is
...
...
up.
...
...
...
These days there's actually usually little if any need for such
functions, since we've got the various hook arrays of all sorts
which
...
...
...
...
are designed for extensibility and lazy-loading; you can set your
various information directly in the arrays in your config/loader
code.
...
...
...

-- brion vibber (brion @ wikimedia.org)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg1ppMACgkQwRnhpk1wk45KkQCg2iSiouyAnhT7lYpdAmjkViVD
WywAoNZ77bk3rTPe+0KKzou3yYn9QpzD
=y7Nd
-----END PGP SIGNATURE-----

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
All of this is great advice (especially for someone new to the
code,
...
...
like
...
...
myself), and would be of great use to be on Mediawiki.org as well.
On
...
...
...
...
that note, perhaps an update of the example extension in SVN might
be
...
...
...
...
in order, with some better documentation, so things like this are
clear
...
...
to
...
everyone.
-Chad

Message: 4
Date: Thu, 22 May 2008 15:31:11 -0400
From: "Edward Z. Yang" edwardzyang@thewritingpot.com
Subject: Re: [Wikitech-l] PHP design basics
To: wikitech-l@lists.wikimedia.org
Message-ID: g14hlu$rei$1@ger.gmane.org
Content-Type: text/plain; charset=UTF-8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Starling wrote:
...
It is nice from a self-documentation standpoint to put var
declarations
...
...
at
...
the top of your classes. But understand that a var declaration
takes
...
up
...
...
...
time and space when the object is initialised. If you leave it
out,
...
...
...
that
...
...
overhead can be deferred, and maybe skipped altogether.
I find this to be a very interesting viewpoint. How much
time/space,
...
...
...
...
exactly, is saved by moving variable declarations from the object
declaration to, say, the constructor? I've always felt that the
self-documentation ability derived from having explicit member
variables
...
...
is more important.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFINcn/qTO+fYacSNoRAni3AJ9D9FrdvfkwuPuTQB3+J8jMp+SkyACdHNLY
AQsHIEzlYn08EuTN7aSxlfQ=
=Oiok
-----END PGP SIGNATURE-----

Message: 5
Date: Thu, 22 May 2008 23:53:23 +0200
From: Roan Kattouw roan.kattouw@home.nl
Subject: Re: [Wikitech-l] So... status of category intersections?
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Message-ID: 4835EB53.8040507@home.nl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Robert Stojnic schreef:
...
Let me briefly repeat what I said earlier about my experience
with
...
...
this
...
...
...
category
intersection thingy. Adding categories to lucene index is easy
*IF*
...
...
...
they
...
...
are inside
the article, e.g. try this:
http://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=%2Binc...
...
...
...
...
...
This will give you category intersection of "Living People" and
"English
...
...
comedy writers"
in fraction of the second.
That's the dirty way. I've gone ahead and written an alternative
way
...
of
...
...
...
implementing category intersections using a fulltext search, which
means
...
...
you can run the most crazy intersections; in fact, you can search
in
...
an
...
...
...
article's categories as if they were the page's contents. It's part
of
...
...
...
the AdvancedSearch extension which I'm paid to write, but it'll be
easy
...
...
...
to split off just the intersection functionality into another
extension.
...
...
The upside is that I also have a special page front end ready to
go.
...
...
...
...
I'll commit AdvancedSearch into SVN once I've worked out the bugs
(provided there are any; it's close to midnight now so I don't
really
...
...
...
...
feel like testing stuff any more) and worked out stuff with my
'employer', which shouldn't take more than a few days.
On a technical level, the extension adds the categorysearch table
(you
...
...
...
need to run update.php to actually create the table), which is
basically
...
...
a rip-off from the searchindex table. It has a cs_page field
referencing
...
...
page_id, and keeps itself updated using the LinksUpdate and
ArticleDeleteComplete hooks. There's also a maintenance script to
populate the table from scratch.
...
What I found that the hard part is keeping the index updated. If
we
...
...
...
want
...
...
a fancy category
intersection system discussed here before we need to have an
index
...
...
that
...
...
...
is frequently updated,
that will be integrated with the job queue, that will understand
templates etc..
Understanding templates is no problem here, since the updater uses
the
...
...
...
parser's notion of which categories the page is in, and the
populate
...
...
...
...
script uses the categorylinks table.
...
Lucene is not that good with very frequent updates. The usual
setting
...
...
is
...
...
to have an indexer,
make snapshots of the index at regular intervals and then rsync
it
...
...
onto
...
...
...
searchers. The whole
process takes time, although for a category-only index it will
probably
...
...
...
be fast. I assume there
would be at least few tens of minutes lag anyhow. Our current
lucene
...
...
...
...
framework could
easily be used for index distribution and such.
I really don't have the faintest idea how Lucene works or how
MediaWiki
...
...
...
interfaces with it, but I do know that Lucene can handle the stuff
we
...
...
...
...
put into the searchindex table. Since the categorysearch table is
no
...
...
...
...
different, I think Lucene *should* be able to handle it pretty
easily
...
...
as
...
...
well. Could someone who actually has a clue about all this reply?
Roan Kattouw (Catrope)

Message: 6
Date: Fri, 23 May 2008 09:45:41 +1000
From: Tim Starling tstarling@wikimedia.org
Subject: Re: [Wikitech-l] PHP design basics
To: wikitech-l@lists.wikimedia.org
Message-ID: g150j7$cak$1@ger.gmane.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Edward Z. Yang wrote:
...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Starling wrote:
> It is nice from a self-documentation standpoint to put var
declarations
...
at
...
> the top of your classes. But understand that a var declaration
takes
...
...
up
...
...
> time and space when the object is initialised. If you leave it
out,
...
...
that
...
...
> overhead can be deferred, and maybe skipped altogether.
I find this to be a very interesting viewpoint. How much
time/space,
...
...
...
...
exactly, is saved by moving variable declarations from the object
declaration to, say, the constructor? I've always felt that the
self-documentation ability derived from having explicit member
variables
...
...
is more important.
Nothing is saved by moving them to the constructor, in fact it'll
probably
...
be slower. The idea is to defer variable initialisation until the
variable
...
is required. The saving, assuming the variable is never required,
is
...
on
...
...
...
the order of a microsecond plus 84 bytes. So unless there's a lot
of
...
...
...
...
objects or it's in a tight loop, we're in the realm of
micro-optimisation,
...
and other considerations, such as personal style, are probably
going
...
to
...
...
...
take precedence.
I wouldn't recommend leaving the var out when there is a need to
initialise it to something simple, and you would need to add an
isset():
...
...
var $x = 1;
...
$this->doStuff( $x );
versus
if ( !isset( $this->x ) ) {
    $this->x = 1;
}
$this->doStuff( $x );
The second one is slower.
But please don't forget my main point: an object is a hashtable,
you
...
...
can
...
...
add and remove variables. Don't be such a stickler for
self-documentation
...
...
and the way things are "meant" to be done that you tie yourself in
knots
...
...
trying to avoid dynamic variable creation. You can always document
with
...
a
...
...
comment instead.
-- Tim Starling

Message: 7
Date: Fri, 23 May 2008 11:59:43 +1000
From: "Nick Jenkins" nickpj@gmail.com
Subject: Re: [Wikitech-l] PHP design basics
To: "Wikimedia developers" wikitech-l@lists.wikimedia.org
Message-ID: JNEIKFDPGFACDNNDIHNMGEICILAA.nickpj@gmail.com
Content-Type: text/plain;       charset="us-ascii"
...
> It is nice from a self-documentation standpoint to put var
declarations
...
at
...
> the top of your classes. But understand that a var declaration
takes
...
up
...
...
> time and space when the object is initialised. If you leave it
out,
...
...
...
that
...
> overhead can be deferred, and maybe skipped altogether.
I find this to be a very interesting viewpoint. How much
time/space,
...
...
...
...
exactly, is saved by moving variable declarations from the object
declaration to, say, the constructor? I've always felt that the
self-documentation ability derived from having explicit member
variables
...
...
is more important.
Yeah, I feel the same. Let me outline why. With any code, there are
at
...
...
...
least 3 dimensions of quality:

Performance. How quickly it does its job, and with what

resources.
...
...
Can
...
...
be improved by
  having short code paths, minimizing memory use, minimizing
compiled
...
...
...
code
...
size (so that more of the program fits
  into L1 or L2 cache), reducing disk access, using low-level
languages
...
...
...
with less runtime overhead (hand-optimized
  assembler in the extreme), various caches (opcode caches, object
caches,
...
HTTP caches, etc), and doing things only
  when you need them (lazy loading, just-in-time systems, etc),
better
...
...
...
algorithms, and so forth. Or performance can
  be improved by increasing the resources allocated (e.g. more
database
...
...
...
servers, more apache servers, more squids,
  more RAM, faster disks, faster CPU, faster network, etc). I.e. do
less,
...
...
and/or do it with more grunt.

Maintenance. How easily and quickly other programmers can fix or

add
...
...
...
functionality to your code when you are away:

documentation. What is the overall purpose of the code, what

problem
...
...
is
...
it trying to solve,
   how are you trying to solve it, what are main functions, what
are
...
...
...
their
...
parameters.

making things obvious. E.g. understandable and short variable

names,
...
...
...
function names, and class names.
   Any bits that do something tricky or critical should be
documented
...
...
or
...
...
explained.

making things short, and simple. Simpler and shorter things are

easier
...
...
to hold in your head and understand.

using a programming language and a style that is familiar to

many
...
...
...
...
people.

Functionality. How much the code does, how useful what it does

is,
...
...
and
...
...
how closely its actual behaviour matches
  the expected behaviour, and how flexible and general the code is.
There way well be more dimensions and other aspects I haven't
covered
...
...
...
...
above, but it'll probably suffice.
I'd argue that most everything that committers are trying to do in
MediaWiki is aimed at giving an improvement in
one or more of the above dimensions. E.g. fix a bug = improved
functionality. Add a feature = improved functionality.
Add some documentation = improved maintenance. Standardize an
awkward
...
...
...
...
non-standard file to use the same approach as
the rest of the code base, which makes it shorter and simpler =
improved
...
...
maintenance. And so forth, with
combinations of the above possible.
I'd also argue that anything that is an overall regression in the
above
...
...
...
dimensions should probably be reverted.
E.g. introduce a bug and make performance worse but add one line of
documentation = revert.
Now, some of the cases outlined are a clear overall win (that is,
they
...
...
...
entail a significant improvement in one
dimension with no regressions in another, or a very minor
regression
...
in
...
...
...
another).
E.g. lazy loading probably makes the code a bit longer, and a tiny
bit
...
...
less
...
clear, but improves performance a lot.
However, not declaring class variables seems to me to be a
significant
...
...
...
overall loss. I for one have looked at MediaWiki
code trying to work out where some variable in a huge class came
from.
...
It
...
...
wasn't declared. It wasn't inherited from the parent
class (which was also very long). It wasn't inherited from the
parent's
...
...
...
parent class. Nope. It wasn't documented anywhere.
It was just used a few times, without explanation, and without
declaration.
...
And to understand what it did you had to read
the function that initialized it. That function was also not
documented.
...
...
And that function called another function which
you had to understand to understand that the first function did.
That
...
...
...
...
function was also not documented. Then that function
called a third function, which you have to understand to understand
what
...
...
the second function did to understand what the
first function did to understand what the purpose of the class
variable
...
...
...
was. The whole process wasted about 20 minutes, and
by the end of it, I was, to say the least, not very impressed. For
a
...
...
...
...
minimal gain in performance by not declaring a
variable (and for zero gain in performance by not having any
documentation), the maintainability of that code was severely
reduced.
So personally, I'm very much in favour of declaring variables (for
the
...
...
...
simple reason that the performance increase would
need to be f*ing huge to counterbalance the enormous reduction in
maintainability). But if people _really_ don't want to do
this for performance reasons, then fair enough, but at the very
least
...
...
can
...
...
they please consider documenting those variables,
with their scope, name, type, and purpose. E.g.

// This class does batch processing for [insert some reason here]
class whatever {
    // Local variables, not declared for performance reasons:
    // private $count int How many pages we have looked at thus far
in
...
...
the
...
batch processing.
    // private $title Title The current page's title that we are
currently
...
working on for the batch processing.
    // ... etc

-- All the best,
Nick.

Message: 8
Date: Fri, 23 May 2008 12:50:49 +1000
From: Tim Starling tstarling@wikimedia.org
Subject: Re: [Wikitech-l] PHP design basics
To: wikitech-l@lists.wikimedia.org
Message-ID: g15bea$3tc$1@ger.gmane.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Nick Jenkins wrote:
...
However, not declaring class variables seems to me to be a
significant
...
...
...
overall loss. I for one have looked at MediaWiki code trying to
work
...
...
...
...
out where some variable in a huge class came from. It wasn't
declared.
...
...
...
It wasn't inherited from the parent class (which was also very
long).
...
...
...
...
It wasn't inherited from the parent's parent class. Nope. It
wasn't
...
...
...
...
...
documented anywhere. It was just used a few times, without
explanation,
...
...
...
and without declaration. And to understand what it did you had to
read
...
...
...
the function that initialized it. That function was also not
documented. And that function called another function which you
had
...
...
to
...
...
...
understand to understand that the first function did. That
function
...
...
was
...
...
...
also not documented. Then that function called a third function,
which
...
...
...
you have to understand to understand what the second function did
to
...
...
...
...
understand what the first function did to understand what the
purpose
...
...
...
...
of the class variable was. The whole process wasted about 20
minutes,
...
...
...
...
and by the end of it, I was, to say the least, not very
impressed.
...
...
For
...
...
...
a minimal gain in performance by not declaring a variable (and
for
...
...
zero
...
...
...
gain in performance by not having any documentation), the
maintainability of that code was severely reduced.
If you've got no clue whatsoever what is going on in a section of
code,
...
...
an
...
uncommented var declaration is hardly going to do you any good. It
seems
...
...
to me your problem is with documentation, not var statements.
-- Tim Starling

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 58, Issue 36

Message: 3
Date: Thu, 22 May 2008 17:09:17 -1000
From: Azu azumao@gmail.com
Subject: [Wikitech-l] STOP IT!!
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222009t370bcd46x6430ec868e5716b7@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
STOP SENDING ME 50 EMAILS A DAY YOU FUCKING PIECE OF SHIT
I REPLACED WITH "unsubscribe" IN THE SUBJECT LIKE 100 TIMES
MOTHERFUCKER
...
SO
...
WHY WON'T YOU STOP SPAMMING ME!!!!

Message: 4
Date: Thu, 22 May 2008 17:09:29 -1000
From: Azu azumao@gmail.com
Subject: [Wikitech-l] STOP IT!!!
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222009j398a0ef7rf0e28f4e148edfd2@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
STOP SENDING ME 50 EMAILS A DAY YOU FUCKING PIECE OF SHIT
I REPLACED WITH "unsubscribe" IN THE SUBJECT LIKE 100 TIMES
MOTHERFUCKER
...
SO
...
WHY WON'T YOU STOP SPAMMING ME!!!!

Message: 5
Date: Thu, 22 May 2008 17:09:39 -1000
From: Azu azumao@gmail.com
Subject: [Wikitech-l] STOP IT!!!!!
To: wikitech-l@lists.wikimedia.org
Message-ID:
       45ac77b00805222009t3603abf6hd6699cdf9392ea66@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
STOP SENDING ME 50 EMAILS A DAY YOU FUCKING PIECE OF SHIT
I REPLACED WITH "unsubscribe" IN THE SUBJECT LIKE 100 TIMES
MOTHERFUCKER
...
SO
...
WHY WON'T YOU STOP SPAMMING ME!!!!

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 58, Issue 37

Message: 2
Date: Thu, 22 May 2008 23:12:58 -0400
From: "Edward Z. Yang" edwardzyang@thewritingpot.com
Subject: Re: [Wikitech-l] PHP design basics
To: wikitech-l@lists.wikimedia.org
Message-ID: g15cnp$6k5$1@ger.gmane.org
Content-Type: text/plain; charset=UTF-8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Starling wrote:
...
I wouldn't recommend leaving the var out when there is a need to
initialise it to something simple, and you would need to add an
isset():
...
...
[snip] The second one is slower.
Right. A little murkier would be something like
var $foo;
Which declares the variable and is a convenient point for
documentation.
...
...
I've always thought that adding this little marker allowed the Zend
Engine to optimize access to the variable, much like a C struct. If I'm
reading you correctly, apparently not! (It's really hard to test for
micro-optimizations like these, and I can't read C well enough to make
determinations on my own).
And, of course, conditional includes, although annoying to bytecode
caches, let you bypass the overhead of loading all the opcodes
altogether. There's a balance to be had there, and I'm curious to know
what works and what doesn't.
...
But please don't forget my main point: an object is a hashtable, you
can
...
...
add and remove variables. Don't be such a stickler for
self-documentation
...
...
and the way things are "meant" to be done that you tie yourself in
knots
...
...
trying to avoid dynamic variable creation. You can always document
with
...
a
...
...
comment instead.
There's an interesting question: why objects over arrays? (There's a
simple answer to that, and it is that most of the time, you're dealing
with an object, not an array, and shouldn't have to allocate another
hash table for some custom properties.)
Also, you might be interested in the "Class Properties in Interfaces?"
discussion that was recently floating around on php.internals, that
proposed that unsetting a variable from an interface should cause a
fatal error. :-P (You're probably not; it's a really long discussion).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFINjY6qTO+fYacSNoRAntiAJ9NczepsswzI8h3Tg0u5WfzmXaq6QCeO2Ww
+peoZNen2GlPtwj0hCx+tFI=
=nVh4
-----END PGP SIGNATURE-----

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 58, Issue 38

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 58, Issue 39

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 58, Issue 40