By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,173 Members | 1,079 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,173 IT Pros & Developers. It's quick & easy.

Why no type hints for built-in types?

P: n/a
Hi.

I'm new here, and sorry if this has been discussed before; I didn't find it
searching the PHP groups. (I've also read recommendations to cross-post to
the other PHP groups, but if that is discouraged, please let me know. At the
same time, please then let me know which of the many PHP groups to post to.
:) )

In PHP5, you can provide "type hints" for functions, like this:

class Person {...}

function f(Person $p)
{
...
}

Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?

I come from a background with generally static and strong typing (C++,
Java), and having worked with PHP a couple of years, I've quite a few times
got bitten by stupid bugs that could have been caught by static typing, such
as passing an empty string - which gets converted to 0 in an arithmetic
context, when the function was supposed to receive a number, or some such,
and no error is reported. These bugs can be hard to find.

This has been suggested in a few Q & A's at Zend, such as this one:
http://www.zend.com/expert_qa/qas.php?id=104&single=1

--- Start quote ---

Will be a support for type hints of simple types, like
class Foo{
public function bar(int $var) { }
}

No, type hints of simple types will not be supported. The reason is
PHP's dynamic nature. A number posted to a script will arrive as a string
even though it's a number. In this case, PHP assumes that "10" and 10 are
the same thing. Having such type hints would not fit into this
auto-conversion of PHP.

--- End quote ---

I don't find this answer satisfactory. Yes, PHP has loose/weak typing, but
at any one time, a value or a variable has a distinct type. In the example
in the quote above, you'd have to ensure that the value you pass is of the
right type.

This would also open the door to overloading, although it seems from the
replies from Andi and Zeev in the Zend forums that neither optional static
typing, nor overloading is considered at this time, and likely not in the
future, either. :/ What I have seen of arguments against it, I haven't found
sufficiently convincing, so therefore I'd like to hear about the pros and
cons of optional static typing, and possibly overloading (however, that
should really be a separate thread). What the PHP manual calls "overloading"
has really nothing to do with the concept of overloading in other OO
languages, such as C++/Java.

There's a rather lively discussion about adding optional static typing in
Python (http://www.artima.com/weblogs/viewpo...?thread=85551), and unless
it has already been, maybe it's time for us to consider it for PHP, as well.
The current static type checking in PHP5 is something rather half-baked,
only covering user-defined types.

Regards,

Terje
Jul 17 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Terje Slettebų wrote:
I don't find this answer satisfactory. Yes, PHP has loose/weak
typing, but at any one time, a value or a variable has a distinct
type. In the example in the quote above, you'd have to ensure that
the value you pass is of the right type.


Not with loose typing. The following example will print 6 because PHP will
try to convert the input to the approriate types:

print 2 * "3 will print 6";

If you want to test for types, use the is_* functions. Yes, this doesn't
work the same as in Java, but PHP isn't Java.
JW

Jul 17 '05 #2

P: n/a
Ahem, in my posts, substitute "static typing" with "explicit/manifest
typing" (specifying the type of variables/parameters). After all, these are
checked at run-time, so a call that's not made won't be checked.

Regards,

Terje
Jul 17 '05 #3

P: n/a
"Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:41***********************@news.euronet.nl...
Terje Slettebų wrote:
I don't find this answer satisfactory. Yes, PHP has loose/weak
typing, but at any one time, a value or a variable has a distinct
type. In the example in the quote above, you'd have to ensure that
the value you pass is of the right type.
Not with loose typing. The following example will print 6 because PHP will
try to convert the input to the approriate types:

print 2 * "3 will print 6";


Yes, but I meant that for for type hints using built-in types to work, you'd
have to ensure the types are right. In your example above, the result would
be of type int, and so would be suitable to use for calling a function
taking a numeric argument. Some auto-conversion might be ok, though, such as
allowing conversion between the "integer" and "float" types. Maybe even
to/from strings, and one might introduce the concept of "best match" for
overloaded functions. There's a question of how complex this would be,
though. The C++ overloading mechanism is insanely complex (especially as it
includes function templates, as well), but it works quite well in practice,
and enables some rather elegant programs.
If you want to test for types, use the is_* functions.


Yes, but that means you have to do this polymorphism "manually", and
switch-on-type really goes against the grain of the type system, in more or
less any language.

Regards,

Terje
Jul 17 '05 #4

P: n/a
["Followup-To:" header set to comp.lang.php.]
On 2005-01-22, Terje Slettebų <ts*******@hotmail.com> wrote:
Hi.

I'm new here, and sorry if this has been discussed before; I didn't find it
searching the PHP groups. (I've also read recommendations to cross-post to
the other PHP groups, but if that is discouraged, please let me know. At the
same time, please then let me know which of the many PHP groups to post to.
:) )
There is only one, and that is c.l.p (all the others are from ages ago)
In PHP5, you can provide "type hints" for functions, like this:

class Person {...}

function f(Person $p)
{
...
}

Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?
That is already happening, not? (php5.0.3)

<?php
function foo(integer $int)
{
echo $int;
}
$bar = 'xx';
foo($bar);
?>

Generates: Fatal error: Argument 1 must be an object of class integer in
F:\websites\test\cast.php on line 3
I come from a background with generally static and strong typing (C++,
Java), and having worked with PHP a couple of years, I've quite a few times
got bitten by stupid bugs that could have been caught by static typing, such
as passing an empty string - which gets converted to 0 in an arithmetic
context, when the function was supposed to receive a number, or some such,
and no error is reported. These bugs can be hard to find.
Thats weird, because in Java (don't know about C++) there is also
implicit casting. The bugs can be quite easily avoided if the code is
writting by someone competent.

The one that writes the function, should make sure all the recieved data is valid.
And the one that uses the function, should not send it false data.
This is valid for both (weak- and strong-typed) languages.
I don't find this answer satisfactory. Yes, PHP has loose/weak typing, but
at any one time, a value or a variable has a distinct type.
That's a contradctio in terminis. If PHP has weak typing, the type of a
variable depends on the context where it is used. (If you really insist,
you could say that because a programmer knows the context, the
programmer also knows as which type that variable is used.)
in the quote above, you'd have to ensure that the value you pass is of the
right type.
You have to do that always. Strong-typed languages require you to do
this even more explicit.
This would also open the door to overloading, although it seems from the
replies from Andi and Zeev in the Zend forums that neither optional static
typing, nor overloading is considered at this time, and likely not in the
future, either. :/
i> What I have seen of arguments against it, I haven't found sufficiently convincing, so therefore I'd like to hear about the pros and
cons of optional static typing, and possibly overloading (however, that
should really be a separate thread). What the PHP manual calls "overloading"
has really nothing to do with the concept of overloading in other OO
languages, such as C++/Java.

Because PHP has weak typing and variable-length arguments lists you can
already overload functions. The only difference is that it doesn't look
the same as in Java/C++

There's a rather lively discussion about adding optional static typing in
Python (http://www.artima.com/weblogs/viewpo...?thread=85551), and unless
it has already been, maybe it's time for us to consider it for PHP, as well.
The current static type checking in PHP5 is something rather half-baked,
only covering user-defined types.


Imho, PHP needs native support for things like multibyte strings much
more than just another OOP-fetisj. If you really want strong-typed
language, Java/J2EE/JSP/JSF seems more appropriate.
--
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>
Jul 17 '05 #5

P: n/a
Tim Van Wassenhove wrote:
That is already happening, not? (php5.0.3) [...] Generates: Fatal error: Argument 1 must be an object of class integer
in F:\websites\test\cast.php on line 3


No, it isn't. Passing an integer will have the same result. Only when you
create a class "integer" and you pass an instance of this class, you will
satisfy the method.
JW

Jul 17 '05 #6

P: n/a
On 2005-01-23, Janwillem Borleffs <jw@jwscripts.com> wrote:
Tim Van Wassenhove wrote:
That is already happening, not? (php5.0.3)

[...]
Generates: Fatal error: Argument 1 must be an object of class integer
in F:\websites\test\cast.php on line 3


No, it isn't. Passing an integer will have the same result. Only when you
create a class "integer" and you pass an instance of this class, you will
satisfy the method.


ACK.

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>
Jul 17 '05 #7

P: n/a
"Tim Van Wassenhove" <ti***@users.sourceforge.net> wrote in message
news:35*************@individual.net...
["Followup-To:" header set to comp.lang.php.]
On 2005-01-22, Terje Slettebų <ts*******@hotmail.com> wrote:
Hi.

I'm new here, and sorry if this has been discussed before; I didn't find it searching the PHP groups. (I've also read recommendations to cross-post to the other PHP groups, but if that is discouraged, please let me know. At the same time, please then let me know which of the many PHP groups to post to.:) )
There is only one, and that is c.l.p (all the others are from ages ago)


Ok, thanks. They still seem to be active, though, but I'll use comp.lang.php
from now on.
In PHP5, you can provide "type hints" for functions, like this:

class Person {...}

function f(Person $p)
{
...
}

Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?


That is already happening, not? (php5.0.3)

<?php
function foo(integer $int)
{
echo $int;
}
$bar = 'xx';
foo($bar);
?>

Generates: Fatal error: Argument 1 must be an object of class integer in
F:\websites\test\cast.php on line 3


No, I'm afraid you're fooling yourself: Try "foo(1)", and it'll give the
same result... The error message above says it: it expects "an object of
_class_ integer". It treats "integer" as some yet-to-be-defined class. It
was a tempting thought, though. :)
I come from a background with generally static and strong typing (C++,
Java), and having worked with PHP a couple of years, I've quite a few times got bitten by stupid bugs that could have been caught by static typing, such as passing an empty string - which gets converted to 0 in an arithmetic
context, when the function was supposed to receive a number, or some such, and no error is reported. These bugs can be hard to find.


Thats weird, because in Java (don't know about C++) there is also
implicit casting.


Yes, there are implicit conversions/casting. However, it's not as "eager" as
in PHP, and therefore typically makes sense. It's stricter in Java than in
C++ (mostly due to its C heritage). In Java, you may implicitly convert
between integers and floating-point values, but _not_ between strings and
these, for example. Even boolean is a distinct type, not implicitly
convertible to another type, so the "if(a=b) ..." bug ("=" instead of "==")
can't happen (unless "a" and "b" are booleans...).
The bugs can be quite easily avoided if the code is writting by someone competent.

Eheh. :) Bugs can still happen to the most competent programmer: We have a
type system so that it may automatically check that the code makes at least
some kind of sense. This way, the programmer is free to focus on more
high-level tasks, such as if the algorithm works.
The one that writes the function, should make sure all the recieved data is valid. And the one that uses the function, should not send it false data.
This is valid for both (weak- and strong-typed) languages.
True, but in general, any help you may get from the compiler/runtime in
checking program is welcome. As mentioned above, it relieves you to
concentrate on higher-level issues, and the compiler will generally catch
the "stupid" bugs (such as typos). For example, getting a notice for using
uninitialised variables helps a lot.

Another thing PHP doesn't check is if you provide _too many_ arguments to a
function. Again, this may be a source of bugs, and this "flexibility" may
cost more than it's worth. For example, say we have the following function
and function call (in separate places):

function f($some_int,$some_string,$some_array) { ... }
....
f(1,"test",array());

Now, some time down the road, we decide that the middle parameter isn't
necessary, anymore, so we remove it:

function f($some_int,$some_array) { ... }

If we _don't_ find all the calls to f() and change them, we've just
introduced a bug that the compiler/runtime won't tell us about, because it
happily calls f() with three arguments... In languages with stricter
checking, this would have been detected.
I don't find this answer satisfactory. Yes, PHP has loose/weak typing, but at any one time, a value or a variable has a distinct type.


That's a contradctio in terminis. If PHP has weak typing, the type of a
variable depends on the context where it is used.


I guess one problem is terminology, yes. Often, strong/weak typing is
defined as whether or not the language will catch type errors
(http://c2.com/cgi/wiki?WeaklyTyped). Extreme examples of weakly typed
languages are BCPL and assembly code, where you may store an int to a
variable, and read it back as a float (and you'll get a garbage value,
because it won't convert it; it just interprets the bits as another type).
However, PHP is not like this: it provides conversions, so you still get
values that may make sense.

Instead, the difference to e.g. C++ or Java is how "eager" it is to convert,
and I don't know if this is defined as something, or if it might in a sense
be considered weak typing, since the conversions may lead to type errors,
nonetheless (calling a function with a wrong type, but it still runs without
errors).

Regarding what you say about "context", isn't really what is happening that
the variable gets _converted_ to an appropriate type, if it's not already of
the right type? This also happens in C++/Java, but to a much less extent,
and they do have explicit typing ("type hints"). I.e.:

$a=1;
var_dump($a); // int(1)
$b="2";
var_dump($b); // string(1) "2"
$c=$a+$b;
var_dump($c); // int(3)
(If you really insist,
you could say that because a programmer knows the context, the
programmer also knows as which type that variable is used.)
Yes, I may insist on that. ;)
Because PHP has weak typing and variable-length arguments lists you can
already overload functions. The only difference is that it doesn't look
the same as in Java/C++
That's not the only difference. See my reply to Matthew in this thread.
There's a rather lively discussion about adding optional static typing in Python (http://www.artima.com/weblogs/viewpo...?thread=85551), and unless it has already been, maybe it's time for us to consider it for PHP, as well. The current static type checking in PHP5 is something rather half-baked,
only covering user-defined types.


Imho, PHP needs native support for things like multibyte strings


Yes, that would be welcome.
much more than just another OOP-fetisj.
Actually it has nothing to do with OO: It has to do with type safety and
program correctness, and I assume you care about that?
If you really want strong-typed language, Java/J2EE/JSP/JSF seems more

appropriate.

Unfortunately, I'm not at the liberty to choose the language of the code
base at work. :) We have non-trivial systems written in PHP, and rewriting
them in another language is just not an option. Besides, I think PHP works
quite well, and is the best language for the task (in particular, I don't
miss having to wait for the compilation. :) ). PHP5 has also improved the
situation a lot (although we need to prepare the codebase, to change to use
PHP5). So I'm just airing some issues and suggestions, to see what the rest
of the community thinks, for things that might make PHP an even better
language, especially now that it's no longer just used in simple scripts.

Regards,

Terje
Jul 17 '05 #8

P: n/a
>From: "Terje Slettebų" <ts*******@hotmail.com>
"Tim Van Wassenhove" <ti***@users.sourceforge.net> wrote in message
news:35*************@individual.net...
["Followup-To:" header set to comp.lang.php.]
On 2005-01-22, Terje Slettebų <ts*******@hotmail.com> wrote:

Because PHP has weak typing and variable-length arguments lists you can
already overload functions. The only difference is that it doesn't look
the same as in Java/C++


That's not the only difference. See my reply to Matthew in this thread.
There's a rather lively discussion about adding optional static typing in Python (http://www.artima.com/weblogs/viewpo...?thread=85551), and unless it has already been, maybe it's time for us to consider it for PHP, as well. The current static type checking in PHP5 is something rather half-baked, only covering user-defined types.


Imho, PHP needs native support for things like multibyte strings


Yes, that would be welcome.
much more than just another OOP-fetisj.


Actually it has nothing to do with OO: It has to do with type safety and
program correctness, and I assume you care about that?


After having sent this, I realised that what you may have referred to was
function overloading, not explicit typing. However, also that doesn't have
anything to do with OO. It's just a useful abstraction, and like OO, enables
polymorphism (you may call the same function name with different arguments).

PHP has, however, another useful kind of polymorphism, in the form of
variable functions and variables, not at least useful for web programming,
which enables you to do things like:

call_user_func("process_".$_GET["action"]);

function process_edit() { ... } // Edit item
function process_update() { ... } // Update item (after POST)
function process_delete() { ... } // Delete item
....

This allows you to avoid clumsy switch-case structures for selecting
appropriate function to call, and you can add new actions simply by adding
new functions for them, and don't have to edit a central switch-case (the
Open-Closed Principle). This technique was also described in a "PHP
Architect" issue, a while ago (actually, in the free example issue, about
event-driven applications), and also the December 2004 issue.

Regards,

Terje
Jul 17 '05 #9

P: n/a
"Terje Slettebų" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...
Hi.

I'm new here, and sorry if this has been discussed before; I didn't find it searching the PHP groups. (I've also read recommendations to cross-post to
the other PHP groups, but if that is discouraged, please let me know. At the same time, please then let me know which of the many PHP groups to post to. :) )

In PHP5, you can provide "type hints" for functions, like this:

class Person {...}

function f(Person $p)
{
...
}

Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?


One reason you can't do it is PHP will automatically promote an int to a
float when it gets too large.

I don't think you should put the burden of supplying the correct type on the
caller anyway. For fundamental types, an implementation should try its best
to coerce arguments to the correct type. If it fails then it returns an
error or raises an exception. This is how COM IDispatch interfaces work.
Jul 17 '05 #10

P: n/a

Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?

One reason you can't do it is PHP will automatically promote an int to a
float when it gets too large.

I don't think you should put the burden of supplying the correct type on the
caller anyway. For fundamental types, an implementation should try its best
to coerce arguments to the correct type. If it fails then it returns an
error or raises an exception. This is how COM IDispatch interfaces work.


Besides, this will not be backward compatible
Jul 17 '05 #11

P: n/a
"Alex Kulikov" <al**@pvl.at> wrote in message
news:0H*****************@news.chello.at...
Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?


One reason you can't do it is PHP will automatically promote an int to a
float when it gets too large.

I don't think you should put the burden of supplying the correct type on the caller anyway. For fundamental types, an implementation should try its best to coerce arguments to the correct type. If it fails then it returns an
error or raises an exception. This is how COM IDispatch interfaces work.


Besides, this will not be backward compatible


What backwards compatibility? The construct "function f(int $n)" is
currently illegal. If you mean that it will behave differently from one
without type hints, then, sure, but so will also a function using object
type hints.

Regards,

Terje
Jul 17 '05 #12

P: n/a
"Chung Leong" <ch***********@hotmail.com> wrote in message
news:__********************@comcast.com...
"Terje Slettebų" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...

In PHP5, you can provide "type hints" for functions, like this:

class Person {...}

function f(Person $p)
{
...
}

Since this is optional static typing for objects, why not make the same
capability available for all types, built-in types included?
One reason you can't do it is PHP will automatically promote an int to a
float when it gets too large.


Ok, so we have the possibility of type change depending on the value. That
makes it a little trickier. Maybe an alternative to "int" and "float" hints
could be something like "number", accepting both. However, if you know your
algorithm won't require larger numbers than int, and that you require
absolute accuracy - no rounding - this might actually be useful, as you may
enforce that using "int" as type hint.

Of course, like in C++ and Java, one could still provide
promotions/conversions, so a function taking int, could be called using a
float, and vice versa, for example.
I don't think you should put the burden of supplying the correct type on the caller anyway. For fundamental types, an implementation should try its best to coerce arguments to the correct type.


Are you speaking in the general sense, here, or "scripting languages" in
particular? There are very good reasons for strong type checking, in
general, and there may also be good reasons for not having it, but given
that some of the most popular languages (C/C++/Java, etc.) have strict
typing (to a varying degree, the newer ones being more strict than the older
ones), I don't think you'll find the majority of people agreeing with you on
this, in general.

The problem with "too eager" conversion - which also happens in C, even
though it may be a little more dangerous, and a little safer, than PHP,
anyway (more dangerous in that you may use invalid casts, getting nonsense
results - much of this has been fixed in C++, and more safe in that it does
have a kind of strong typing - you have to explicitly convert between
numbers and strings, for example).

In any case, as mentioned, promotions/conversions could still be used with
type hints, or overloading. After all, that's how it is in C++ and Java. To
take some examples:

void f(int i) {} // #1
void f(double f) {} // #2
void g(int i) {} // #3
void h(double f) {} // #4

int main()
{
f(1); // Calls #1
f(1.0); // Calls #2

g(1); // Calls #3
g(1.0); // Calls #3 (double->int conversion)

h(1); // Calls #4 (int->double conversion)
h(1.0); // Calls #4
}

As you can see, overloading and conversions can coexist quite happily. The
key is finding a function call that is the "best match". If there are none,
you get an ambiguity.

Regards,

Terje
Jul 17 '05 #13

P: n/a
"Terje Slettebų" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...

The problem with "too eager" conversion - which also happens in C, even
though it may be a little more dangerous, and a little safer, than PHP,
anyway (more dangerous in that you may use invalid casts, getting nonsense
results - much of this has been fixed in C++, and more safe in that it does have a kind of strong typing - you have to explicitly convert between
numbers and strings, for example).


I see I never finished that sentence. :) So to finish it:

is that it may mask errors or make them harder to diagnose, such as passing
an object to a function expecting a number, and it "bombs out" inside the
function, somewhere, with perhaps hardly any clue to what the actual error
was, rather than getting an error at the function call about type mismatch.
A more dangerous version is to silently get wrong results, such as the
function returning null, which then gets converted to 0, and everything
looks just fine....

Regards,

Terje
Jul 17 '05 #14

P: n/a
Terje Slettebų wrote:
"Terje Slettebų" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...

The problem with "too eager" conversion - which also happens in C,
even though it may be a little more dangerous, and a little safer,
than PHP, anyway (more dangerous in that you may use invalid casts,
getting nonsense results - much of this has been fixed in C++, and
more safe in that it does have a kind of strong typing - you have to
explicitly convert between numbers and strings, for example).


I see I never finished that sentence. :) So to finish it:

is that it may mask errors or make them harder to diagnose, such as
passing an object to a function expecting a number, and it "bombs
out" inside the function, somewhere, with perhaps hardly any clue to
what the actual error was, rather than getting an error at the
function call about type mismatch. A more dangerous version is to
silently get wrong results, such as the function returning null,
which then gets converted to 0, and everything looks just fine....


You are absolutely correct. But this take us back to the issue of
strongly-typed vs. weakly-typed languages. PHP is a weakly-typed language,
just like Python, Perl or Smalltalk (the paramount OO language), and you
should get used to that.

And weakly-typed languages, just for the reasons you mentioned, benefit the
most from TTD, so use that if you have a problem with weak types.

Berislav
Jul 17 '05 #15

P: n/a
Berislav Lopac wrote:
Terje Slettebų wrote:
"Terje Slettebų" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...

The problem with "too eager" conversion - which also happens in C,
even though it may be a little more dangerous, and a little safer,
than PHP, anyway (more dangerous in that you may use invalid casts, getting nonsense results - much of this has been fixed in C++, and
more safe in that it does have a kind of strong typing - you have to explicitly convert between numbers and strings, for example).
I see I never finished that sentence. :) So to finish it:

is that it may mask errors or make them harder to diagnose, such as
passing an object to a function expecting a number, and it "bombs
out" inside the function, somewhere, with perhaps hardly any clue to what the actual error was, rather than getting an error at the
function call about type mismatch. A more dangerous version is to
silently get wrong results, such as the function returning null,
which then gets converted to 0, and everything looks just fine....


You are absolutely correct. But this take us back to the issue of
strongly-typed vs. weakly-typed languages. PHP is a weakly-typed

language, just like Python, Perl or Smalltalk (the paramount OO language), and you should get used to that.

And weakly-typed languages, just for the reasons you mentioned, benefit the most from TTD, so use that if you have a problem with weak types.


Yes, tests certainly help, regardless of language. However, I still
feel this is complementary to automatic type-checking, as there's a
large class of errors that may be caught by the compiler/runtime
(type-related errors), so that you may concentrate on testing more
high-level things.

When I've been doing C++, it's often been the case that when a program
finally compiles without errors, it's correct, too. In PHP, that a
source file parses successfully, doesn't mean a lot...

Regards,

Terje

Jul 17 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.