Introducing "Array Of" RFC

11 years ago by Andrey Andreev — view source — reply

unread

Am I the only one who finds both proposed syntaxes somewhat confusing?

The originally proposed 'Bar[]' simply looks strange.

HHVM's introduces even more "special characters" (<, >, ?) to parse, looks
a bit like a regular expression and it was even already mentioned that it's
"imported" from C++ ... PHP is not C++, and why should it be?

So, how about this:

Array[Bar] $a - $a is array containing only instances of Bar
Array[Bar|null] $a - $a is array containing Bar instances or nulls
Array[Bar] $a = null - $a is either null or array containing only
instances of Bar
Array[Bar|null] $a = null - above, but the array can contain nulls

It's easily readable and everybody should be able to recognize what this
thing does even without prior knowledge.

Hell, why not Array[Foo|Bar|stdClass|whocares] ?

Or even (at a later stage):

Array[]["key1", "key2"]

... which would hint for a numeric index array containing associative
arrays that in turn must have the defined keys. This is indeed a bit crazy,
but possible to add in the future without BC breaks. You could even shove
scalar typehints in there as soon as they are implemented.

Cheers.
Andrey.

11 years ago by Andrea Faulds — view source — reply

unread

Am I the only one who finds both proposed syntaxes somewhat confusing?

The originally proposed 'Bar[]' simply looks strange.

It is, however, familiar to C, C++, C# and Java users.

So, how about this:

Array[Bar] $a - $a is array containing only instances of Bar
Array[Bar|null] $a - $a is array containing Bar instances or nulls
Array[Bar] $a = null - $a is either null or array containing only
instances of Bar
Array[Bar|null] $a = null - above, but the array can contain nulls

That doesn't make much sense as a syntax, IMO. It looks like "Bar" is
the index of the Array here. Surely it could use angle brackets, which
would be familiar to people who've dealt with generics (C++, C#, Java
users):

  Array<Bar> $a

It's easily readable and everybody should be able to recognize what this
thing does even without prior knowledge.

It's not clear to me at all at first glance. Is that a Bar-indexed array?

Or even (at a later stage):

Array[]["key1", "key2"]

... which would hint for a numeric index array containing associative
arrays that in turn must have the defined keys. This is indeed a bit crazy,
but possible to add in the future without BC breaks. You could even shove
scalar typehints in there as soon as they are implemented.

...that's even less intuitive to me.

Andrea Faulds
http://ajf.me/

11 years ago by Andrey Andreev — view source — reply

unread

Okay, so <Bar> for contents and [Bar] for keys, although AFAIK you can't
use objects as array keys.
These were all random thoughts, I haven't though about it all in depth.
Still, I believe it's more intuitive than both previous proposals.

Am I the only one who finds both proposed syntaxes somewhat confusing?

The originally proposed 'Bar[]' simply looks strange.

It is, however, familiar to C, C++, C# and Java users.

So, how about this:

Array[Bar] $a - $a is array containing only instances of Bar
Array[Bar|null] $a - $a is array containing Bar instances or nulls
Array[Bar] $a = null - $a is either null or array containing only
instances of Bar
Array[Bar|null] $a = null - above, but the array can contain nulls

That doesn't make much sense as a syntax, IMO. It looks like "Bar" is the
index of the Array here. Surely it could use angle brackets, which would be
familiar to people who've dealt with generics (C++, C#, Java users):
 Array<Bar> $a
It's easily readable and everybody should be able to recognize what this

thing does even without prior knowledge.

It's not clear to me at all at first glance. Is that a Bar-indexed array?

Or even (at a later stage):

Array[]["key1", "key2"]

... which would hint for a numeric index array containing associative
arrays that in turn must have the defined keys. This is indeed a bit
crazy,
but possible to add in the future without BC breaks. You could even shove
scalar typehints in there as soon as they are implemented.

...that's even less intuitive to me.

Andrea Faulds
http://ajf.me/

11 years ago by Sara Golemon — view source — reply

unread

One last comment in favor of the HHVM syntax:

We're written (and will very soon be releasing, I promise) a static
analysis tool which looks at your entire code base and determines
types for every local variable in use and tells you (without having to
run the program) where you have type issues. This means two things:

No need to do runtime checks (Which impact performance)
No need to get to 100% code-coverage to guarantee type safety.

And the type-checker can run in the background re-evaluating the files
as they're updated for instant notification.

If PHP were to follow HHVM's syntax, we'd get the type-checker as a
freebie. (If and when we took on return and scalar type hints as
well)

-Sara

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

If PHP were to follow HHVM's syntax, we'd get the type-checker as a
freebie. (If and when we took on return and scalar type hints as
well)

I'm pretty sure if such tool were open source, it would not be hard to
patch it to follow any syntax, provided underlying sematics is the same.
It probably parses the code into some kind of internal representation
anyway, so by slightly changing that parser you will be able to
accommodate any syntax.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

11 years ago by Alexander M — view source — reply

unread

What I find interesting is that the title of the RFC is "Array Of",
proposing a type hint for an "array of Foo". In my opinion the proposed
syntax however reads more as "Foos in an array"?

Foo[] => Foo in/as an array
array<Foo> => array of Foo

I personally like the idea of array<Foo> because it seems to leave more
room for improvements and additions over time (nesting array<array<Foo>>,
k/v typehints array<Foo, Bar>).

Best,
Alexander

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

It's easily readable and everybody should be able to recognize what this
thing does even without prior knowledge.

Hell, why not Array[Foo|Bar|stdClass|whocares] ?

Or even (at a later stage):

Array[]["key1", "key2"]

I don't think inventing another language to specify types inside PHP is
a good idea. If somebody is really into type calculus, there are many
academic languages to play with. In practice, such byzantine constructs
rarely make developer's work easier on tasks that PHP is commonly
applied to. If you want a language that can run code to check if your
array conforms to arbitrary set of rules, what's wrong with PHP language?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

11 years ago by Andrey Andreev — view source — reply

unread

On Fri, Jan 17, 2014 at 1:05 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

It's easily readable and everybody should be able to recognize what this
thing does even without prior knowledge.

Hell, why not Array[Foo|Bar|stdClass|whocares] ?

Or even (at a later stage):

Array[]["key1", "key2"]

I don't think inventing another language to specify types inside PHP is
a good idea. If somebody is really into type calculus, there are many
academic languages to play with. In practice, such byzantine constructs
rarely make developer's work easier on tasks that PHP is commonly
applied to. If you want a language that can run code to check if your
array conforms to arbitrary set of rules, what's wrong with PHP language?

Maybe I wasn't clear enough about it, but I did note several times that
what you quoted is not in the current scope of the RFC we're discussing.
I was trying to explain how this syntax would be forward-compatible and
instead of commenting on my main point, you take this single part out of
context and somehow manage to twist it like I was saying something against
PHP - not cool.

Anyway, I'm not attempting to invent another language (or rather, a
"sub-language") for type hinting. In fact, I was trying to make it more
similar to PHP's current syntax. Array typehints currently are written via
the 'Array' keyword, hence why I find the originally proposed 'className[]'
to be a bit bizzare. The '|' character is indeed new into this, but it is
close enough to the || "or" operator that everybody is familiar with and a
comma wouldn't really hint at "or" at first glance.

Cheers,
Andrey.

11 years ago by Andrey Andreev — view source — reply

unread

Yes, the implementation of this type hint is very limiting in nature.
It's not that I don't like the idea of an array type hint. I just don't
like this implementation. I'd much rather see something like the HHVM
implementation Sara spoke of that actually doesn't constrain the
implementation to such limiting use cases as those you have exhibited

It is an RFC, not a vote. I personally wasn't trying to reject this feature
while proposing an alternative syntax, and my guess is that Sara Golemon
didn't either. The goal is to improve on it.

Cheers,
Andrey.

11 years ago by Andrey Andreev — view source — reply

unread

Please excuse my lack of knowledge, but if I understand this correctly,
this is how generics would work ... using arrays, ignore the syntax and
details such as child classes, interfaces, etc.:

$fruits = Array<Fruit>; - declare that $fruits is an array that can only
contain instances of class Fruit
function eat(Array<Fruit> $apples) - function eat() will only accept
arrays that are declared in the same way as $fruits above

If that is so, then I deffinately see how this RFC is similar to generics
and how generics would give us higher performance. But I also see how it is
different and how it serves for another (yet indeed similar) purpose.

I wouldn't rule out either feature, but if that is what you people want,
why don't you vote on:

a) array of; b) generics; c) both

and be done with it. I surely do understand why Phil Sturgeon got so heated
about the discussion going nowhere - at least 3 separate topics are being
discussed here and everybody has an opinion on all of them separately. This
isn't productive.

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

Please excuse my lack of knowledge, but if I understand this correctly,
this is how generics would work ... using arrays, ignore the syntax and
details such as child classes, interfaces, etc.:

$fruits = Array<Fruit>; - declare that $fruits is an array that can only
contain instances of class Fruit
function eat(Array<Fruit> $apples) - function eat() will only accept
arrays that are declared in the same way as $fruits above

There's two ways to understand "will only accept":

There's a class/type which I call ArrayOfFruit for simplicity. eat()
checks if $apples is instance of ArrayOfFruit. Some magic inside
ArrayOfFruit ensures ArrayOfFruit always contains only Fruit.
eat() goes over $apples which is a regular array, and checks if every
element in it is instanceof Fruit.

First way is essentially templates, second is not. So far I've seen most
advocacy in this RFC to go towards the second way.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

11 years ago by Andrea Faulds — view source — reply

unread

Hi!
Please excuse my lack of knowledge, but if I understand this correctly,
this is how generics would work ... using arrays, ignore the syntax and
details such as child classes, interfaces, etc.:
$fruits = Array<Fruit>; - declare that $fruits is an array that can only
contain instances of class Fruit
function eat(Array<Fruit> $apples) - function eat() will only accept
arrays that are declared in the same way as $fruits above
There's two ways to understand "will only accept":

There's a class/type which I call ArrayOfFruit for simplicity. eat()
checks if $apples is instance of ArrayOfFruit. Some magic inside
ArrayOfFruit ensures ArrayOfFruit always contains only Fruit.

eat() goes over $apples which is a regular array, and checks if every
element in it is instanceof Fruit.

First way is essentially templates, second is not. So far I've seen most
advocacy in this RFC to go towards the second way.

Myself, I want 2 now with syntax that will eventually work for 1 too in
the future. Soft generics. Array could implicitly cast to Array<Fruit>
so long as all its members are fruit, in future. But for now, it will
only be 2. This adds an incentive to add generics: better performance by
not requiring a runtime check when an Array<Fruit> is passed an not an
Array of Fruit.

--
Andrea Faulds
http://ajf.me/

11 years ago by Philip Sturgeon — view source — reply

unread

Please excuse my lack of knowledge, but if I understand this correctly,
this is how generics would work ... using arrays, ignore the syntax and
details such as child classes, interfaces, etc.:

$fruits = Array<Fruit>; - declare that $fruits is an array that can only
contain instances of class Fruit
function eat(Array<Fruit> $apples) - function eat() will only accept
arrays that are declared in the same way as $fruits above

If that is so, then I deffinately see how this RFC is similar to generics
and how generics would give us higher performance. But I also see how it is
different and how it serves for another (yet indeed similar) purpose.

I wouldn't rule out either feature, but if that is what you people want,
why don't you vote on:
a) array of; b) generics; c) both
and be done with it. I surely do understand why Phil Sturgeon got so heated
about the discussion going nowhere - at least 3 separate topics are being
discussed here and everybody has an opinion on all of them separately. This
isn't productive.

The conversation certainly escalated, but not through my doing. I
didn't say the conversation was going nowhere, I said much of it was
not discussing relevant points.

This was down to confusion on some points, only one of which was
generics. There are two things being discussed as one by many, which
is causing confusion for me and probably for others too.

Generics, instead of Array Of
Generics syntax for Array Of

With some people suggesting generics (not Sara) and some suggesting
just taking the syntax and using it for array of instead to add "weak
generics kinda" then we are crossing threads a little.

A vote would certainly help to work out which way people would like to go.

Some bullet points.

Generics are fine.
Generics later are fine.
Generics now would require a big recode, so that would be PHP 6 - not now.
Array of is simple, and could be done instead.
Array of and generics can both live in peace.
Both could use the same syntax - and we can talk about that, but that
can potentially confuse the user. Discussion on that is fine.

As long as we are clear about what is being discussed and proposed,
because there are a lot of routes:

Array of as is, no generics (for now...?)
Array of and generics, different syntax
Array of and generics, same syntax
No array of, let Generics do all of the work

If 4 is picked then it wont be done until a major version. 2 or 3
would need more discussion and delay things a bunch, 1 would get
things going.

I don't want to stifle discussion, but you can see why it would be
beneficial to avoid a contentious subject which is not completely the
same thing.

11 years ago by Philip Sturgeon — view source — reply

unread

From the survey I posted (
http://grokbase.com/p/php/php-internals/141rva4cf7/php-dev-vote-array-of-v-generics
) the most popular option seemed to be "C) I want both".

While I am not just blindly suggesting we copy Java, they do have both
features with different syntax, so the idea for this RFC is going to
be: keep on trucking with the array of syntax and we put it to a vote.
If people do not like the RFC as it is then we can revisit the syntax,
but as people are interested in both features it just makes sense to
assume this syntax is up for the job.

The only open question remaining is:

Should null be an acceptable value inside the array, or can it only
contain items of the type specified?

The following equivalent code will explain the difference:

foreach ($foos as $foo) {
if (! $foo instanceof Face) {
throw new Exception ('AAAGGGGGHHH!');
}
}

foreach ($foos as $foo) {
if (! is_null($foo) and ! $foo instanceof Face) {
throw new Exception ('AAAGGGGGHHH!');
}
}

Logic suggests to me that A makes more sense, as if you ask
specifically for an array of "Face" and want to act on it like every
single item is an instance of "Face", then letting null's slip into
there just adds more boilerplate and introduces a second - and totally
uneccessary - array traversal to find them or remove them.

So, should we allow nulls in an arrayof-style type hint?

11 years ago by Marco Pivetta — view source — reply

unread

So, should we allow nulls in an arrayof-style type hint?

null has its own type, which is mismatching the type required by the
array-of syntax when requesting, for example, Foo[].

If null was allowed in the array, as a user, I'd still be forced to
array_filter() on every call, so it would defeat the new feature
completely.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

11 years ago by Larry Garfield — view source — reply

unread

So, should we allow nulls in an arrayof-style type hint?

null has its own type, which is mismatching the type required by the
array-of syntax when requesting, for example, Foo[].

If null was allowed in the array, as a user, I'd still be forced to
array_filter() on every call, so it would defeat the new feature
completely.

^^ My general stance. (Unless an "allow both" syntax is possible; if
not, the above.)

--Larry Garfield

11 years ago by Crypto Compress — view source — reply

unread

Hello List,

So, should we allow nulls in an arrayof-style type hint?

No. Null values (optional values) should be allowed within an
nullable-arrayof-style type hint.

Compare: function foo(Bar $baz = null)
and: function foo(Bar $baz)

This is not the same syntax and null is not a type.

cryptocompress

11 years ago by Chris Wright — view source — reply

unread

On 28 February 2014 08:11, Crypto Compress
cryptocompress@googlemail.com wrote:

Hello List,

So, should we allow nulls in an arrayof-style type hint?

No. Null values (optional values) should be allowed within an
nullable-arrayof-style type hint.

Compare: function foo(Bar $baz = null)
and: function foo(Bar $baz)

This is not the same syntax and null is not a type.

Are you suggesting the following?

function foo(Bar[] $bars) // required to pass an array of Bar objects
function foo(Bar[] $bars = null) // required to pass an array of Bar
or null members

...because if so, how do I specify an optional array of Bar objects?
And how do I specify an optional array of Bar or null?

The whole concept of allowing null members seems to completely defeat
the purpose of the ArrayOf hint for me. I can understand wanting to
make the parameter optional, but I cannot see a use case for null
members from the point of view of the caller. I never null out members
of an array, I only omit them from the declaration or remove the
member from the array via e.g. unset() or stack operations (pop(),
shift() etc). YMMV of course, but for me allowing null members just
makes the callee's life more difficult and does not gain anything.

11 years ago by Crypto Compress — view source — reply

unread

Are you suggesting the following?

function foo(Bar[] $bars) // required to pass an array of Bar objects
function foo(Bar[] $bars = null) // required to pass an array of Bar
or null members

No. This is ambiguous, as you imply. I prefer c# syntax.

...because if so, how do I specify an optional array of Bar objects?
And how do I specify an optional array of Bar or null?

The whole concept of allowing null members seems to completely defeat
the purpose of the ArrayOf hint for me. I can understand wanting to
make the parameter optional, but I cannot see a use case for null
members from the point of view of the caller. I never null out members
of an array, I only omit them from the declaration or remove the
member from the array via e.g. unset() or stack operations (pop(),
shift() etc). YMMV of course, but for me allowing null members just
makes the callee's life more difficult and does not gain anything.

Have to agree, there is not too much value in this. ;)
Usecase: No need to write a mock for third and seventh array element. In
fact i can't think of other usecases. It's only a simple logical
extension of "function (A $a = null)".

11 years ago by Lester Caine — view source — reply

unread

Chris Wright wrote:

YMMV of course, but for me allowing null members just
makes the callee's life more difficult and does not gain anything.

Practical example ...
Object is a genealogical record. The initial tree has blank parent and
grandparent objects, with each subsequent layer adding more 'null' entries. Now
it may be that the preferred method of working is to create 'empty' objects for
each of these, but with the number of entries doubling with each generation,
'null' is the fastest option since it does not require any processing at create
time. A null entry just flags an empty branch and one only has to track those
branches where there are populated objects.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

11 years ago by Philip Sturgeon — view source — reply

unread

So, should we allow nulls in an arrayof-style type hint?

null has its own type, which is mismatching the type required by the
array-of syntax when requesting, for example, Foo[].

If null was allowed in the array, as a user, I'd still be forced to
array_filter() on every call, so it would defeat the new feature
completely.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

I completely agree with you and the other folks saying: "Allowing
nulls would defeat the new feature completely". Personally I would not
see myself using the "Foo or null", and if I wanted to in the future I
could very easily just not type hint the array.

So, should we allow nulls in an arrayof-style type hint?

I previously suggested using the C#-style ? to specify nullability. Why
can't we do that?

--
Andrea Faulds
http://ajf.me/

We could potentially add in the ? syntax later on, if people seemed to
want the feature enough?
Just to make sure we are on the same page here, nullable arrays are
fine. Arrays with nulls inside are not.

Both of these are acceptable:

function foo(Bar[] $baz) // accepts [new Bar, new Bar]
function foo(Bar[] $baz = null) // accepts [new Bar, new Bar] or null

Some people are suggesting the following alternatives.

Let nulls in there regardless of default var hinting:

function foo(Bar[] $baz) // accepts [new Bar, null, new Bar, null]
function foo(Bar[] $baz = null) // accepts [new Bar, null, new
Bar, null] or null

This is what many describe as a completely useless version of the
feature, as array_filter would need to be run to ensure you're only
working with objects of a certain type (which is 90% of the use-case
for this RFC).

Or, 2. Offer optional syntax for arrays containing nulls

function foo(Bar[]? $baz) // accepts [new Bar, null, new Bar, null]
function foo(Bar[]? $baz = null) // accepts [new Bar, null, new

Bar, null] or null

Pro: Keeps nulls out of the array by default, offers a way to say "Bar or null"
Con: Potentially syntax soup.

11 years ago by Robert Stoll — view source — reply

unread

-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Friday, February 28, 2014 2:54 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC

So, should we allow nulls in an arrayof-style type hint?

null has its own type, which is mismatching the type required by the
array-of syntax when requesting, for example, Foo[].

If null was allowed in the array, as a user, I'd still be forced to
array_filter() on every call, so it would defeat the new feature
completely.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

I completely agree with you and the other folks saying: "Allowing
nulls would defeat the new feature completely". Personally I would not
see myself using the "Foo or null", and if I wanted to in the future I
could very easily just not type hint the array.

So, should we allow nulls in an arrayof-style type hint?

I previously suggested using the C#-style ? to specify nullability. Why
can't we do that?

--
Andrea Faulds
http://ajf.me/

We could potentially add in the ? syntax later on, if people seemed to
want the feature enough?
Just to make sure we are on the same page here, nullable arrays are
fine. Arrays with nulls inside are not.

Both of these are acceptable:
function foo(Bar[] $baz) // accepts [new Bar, new Bar]
function foo(Bar[] $baz = null) // accepts [new Bar, new Bar] or null
Some people are suggesting the following alternatives.

Let nulls in there regardless of default var hinting:

function foo(Bar[] $baz) // accepts [new Bar, null, new Bar, null]
function foo(Bar[] $baz = null) // accepts [new Bar, null, new
Bar, null] or null

This is what many describe as a completely useless version of the
feature, as array_filter would need to be run to ensure you're only
working with objects of a certain type (which is 90% of the use-case
for this RFC).

Or, 2. Offer optional syntax for arrays containing nulls
function foo(Bar[]? $baz) // accepts [new Bar, null, new Bar, null]
function foo(Bar[]? $baz = null) // accepts [new Bar, null, new
Bar, null] or null

Pro: Keeps nulls out of the array by default, offers a way to say "Bar or null"
Con: Potentially syntax soup.

--

I brought up that null in an array is a valid use case at the beginning of this discussion and that the RFC should deal
with such use cases - otherwise it is incomplete. I still claim it is incomplete if this topic is not addressed but I am
happy if option 2 is implemented later on.

11 years ago by Philip Sturgeon — view source — reply

unread

I brought up that null in an array is a valid use case at the beginning of this discussion and that the RFC should deal
with such use cases - otherwise it is incomplete. I still claim it is incomplete if this topic is not addressed but I am
happy if option 2 is implemented later on.

Ok. It seems to be fairly well agreed that null should not be in the
array by default, but there may be cases where it can be allowed,
probably with syntax.

A follow-up RFC can be introduced to add an extra symbol to this, if
people want it. I'm going to put the vote through as is and if people
are not happy about Array Of as is they can simply vote no.

11 years ago by Lazare Inepologlou — view source — reply

unread

2014-02-28 9:11 GMT+01:00 Crypto Compress cryptocompress@googlemail.com:

Hello List,

So, should we allow nulls in an arrayof-style type hint?

No. Null values (optional values) should be allowed within an
nullable-arrayof-style type hint.

Compare: function foo(Bar $baz = null)
and: function foo(Bar $baz)

This is not the same syntax and null is not a type.

I do not really understand your point here but I want to shout out that
null is definitely a type having only one possible value. This is one thing
that PHP got right in contrast to Java, C# etc.

Lazare INEPOLOGLOU
Ingénieur Logiciel

cryptocompress

11 years ago by Crypto Compress — view source — reply

unread

I do not really understand your point here but I want to shout out
that null is definitely a type having only one possible value. This is
one thing that PHP got right in contrast to Java, C# etc.

class Foo {
private Bar $bar; // What type is $bar with "undefiend" value here?
}

In PHP there is no type system, so it might seem as this is of type
"null". It is not.

11 years ago by Andrea Faulds — view source — reply

unread

So, should we allow nulls in an arrayof-style type hint?

I previously suggested using the C#-style ? to specify nullability. Why can’t we do that?

--
Andrea Faulds
http://ajf.me/

Introducing "Array Of" RFC

...that's even less intuitive to me.

...that's even less intuitive to me.

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL