Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5205 > unrolled thread

Class.forName().newInstance() vs new

Back to article view | Back to comp.lang.java.programmer

Contents

  Class.forName().newInstance() vs new Abu Yahya <abu_yahya@invalid.com> - 2011-06-11 22:43 +0530
    Re: Class.forName().newInstance() vs new David Lamb <dalamb@cs.queensu.ca> - 2011-06-11 13:46 -0400
    Re: Class.forName().newInstance() vs new Robert Klemme <shortcutter@googlemail.com> - 2011-06-11 19:49 +0200
      Re: Class.forName().newInstance() vs new Patricia Shanahan <pats@acm.org> - 2011-06-11 11:04 -0700
        Re: Class.forName().newInstance() vs new Abu Yahya <abu_yahya@invalid.com> - 2011-06-11 23:52 +0530
        Re: Class.forName().newInstance() vs new Robert Klemme <shortcutter@googlemail.com> - 2011-06-12 14:05 +0200
          Re: Class.forName().newInstance() vs new Patricia Shanahan <pats@acm.org> - 2011-06-12 07:10 -0700
            Re: Class.forName().newInstance() vs new Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-12 14:37 +0000
              Re: Class.forName().newInstance() vs new Robert Klemme <shortcutter@googlemail.com> - 2011-06-12 18:17 +0200
                Re: Class.forName().newInstance() vs new Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-12 15:25 -0400
              Re: Class.forName().newInstance() vs new lewbloch <lewbloch@gmail.com> - 2011-06-15 06:58 -0700
                Re: Class.forName().newInstance() vs new Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-06-16 10:16 +0100
            Re: Class.forName().newInstance() vs new Robert Klemme <shortcutter@googlemail.com> - 2011-06-12 18:10 +0200
      Re: Class.forName().newInstance() vs new Abu Yahya <abu_yahya@invalid.com> - 2011-06-11 23:53 +0530
        Re: Class.forName().newInstance() vs new "John B. Matthews" <nospam@nospam.invalid> - 2011-06-11 15:43 -0400
          Re: Class.forName().newInstance() vs new "John B. Matthews" <nospam@nospam.invalid> - 2011-06-11 15:50 -0400
            Re: Class.forName().newInstance() vs new lewbloch <lewbloch@gmail.com> - 2011-06-15 06:49 -0700
              Re: Class.forName().newInstance() vs new Michael Wojcik <mwojcik@newsguy.com> - 2011-06-16 11:21 -0400
                Re: Class.forName().newInstance() vs new lewbloch <lewbloch@gmail.com> - 2011-06-17 06:45 -0700
                  Re: Class.forName().newInstance() vs new Michael Wojcik <mwojcik@newsguy.com> - 2011-06-17 12:29 -0400
                    Re: Class.forName().newInstance() vs new Lewis Bloch <lewisbloch@google.com> - 2011-06-17 11:07 -0700
                      Re: Class.forName().newInstance() vs new "John B. Matthews" <nospam@nospam.invalid> - 2011-06-18 02:01 -0400
                    Re: Class.forName().newInstance() vs new Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-18 10:19 -0300
                      Re: Class.forName().newInstance() vs new Robert Klemme <shortcutter@googlemail.com> - 2011-06-18 20:16 +0200
                      OT language stuff (was Re: Class.forName().newInstance() vs new) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-20 19:19 +0000
                        Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-20 20:46 +0000
                          Re: OT language stuff (was Re: Class.forName().newInstance() vs new) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-21 20:42 +0000
                            Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Gene Wirchenko <genew@ocis.net> - 2011-06-21 14:22 -0700
                        Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-20 18:55 -0300
                          Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Tom Anderson <twic@urchin.earth.li> - 2011-06-21 23:29 +0100
                            Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-21 20:39 -0300
                              Re: OT language stuff (was Re: Class.forName().newInstance() vs new) "John B. Matthews" <nospam@nospam.invalid> - 2011-06-21 23:00 -0400
                                Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Tom Anderson <twic@urchin.earth.li> - 2011-06-22 20:02 +0100
                                Re: OT language stuff (was Re: Class.forName().newInstance() vs new) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-22 20:03 +0000
                                  Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 12:04 -0400
                                Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 11:58 -0400
                      Re: Class.forName().newInstance() vs new Gene Wirchenko <genew@ocis.net> - 2011-06-20 14:01 -0700
                        Re: Class.forName().newInstance() vs new Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-20 18:53 -0300
                      Re: Class.forName().newInstance() vs new Michael Wojcik <mwojcik@newsguy.com> - 2011-06-21 19:53 -0400
                        Re: Class.forName().newInstance() vs new blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-22 20:01 +0000
                          Re: Class.forName().newInstance() vs new Michael Wojcik <mwojcik@newsguy.com> - 2011-06-23 12:16 -0400
                  OT language stuff (was Re: Class.forName().newInstance() vs new) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-20 19:18 +0000
                    Re: OT language stuff (was Re: Class.forName().newInstance() vs new) Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-20 20:52 +0000
          Re: Class.forName().newInstance() vs new Robert Klemme <shortcutter@googlemail.com> - 2011-06-12 14:14 +0200
    Re: Class.forName().newInstance() vs new Patricia Shanahan <pats@acm.org> - 2011-06-11 11:01 -0700
    Re: Class.forName().newInstance() vs new Roedy Green <see_website@mindprod.com.invalid> - 2011-06-13 06:16 -0700
    Re: Class.forName().newInstance() vs new Ian Shef <invalid@avoiding.spam> - 2011-06-14 20:07 +0000

Page 1 of 3  [1] 2 3  Next page →

#5205 — Class.forName().newInstance() vs new

I have a class that instantiates a private member based on a value in a 
configuration file.

The value is used to determine the class name.

I initially decided to use code similar to the following:


             // class name comes from property file
             String dbMgrClassName = props.getProperty("db.manager");
             Class<?> k = Class.forName(dbMgrClassName);
             db = (DB) k.newInstance();
             db.init(props);

However, a colleague pointed out that using "new" is faster than using 
"Class.forName().newInstance()". So, I changed the code to the following:

             String dbMgrClassName = props.getProperty("db.manager");
             if (dbMgrClassName.equals("DB2"))
                 db = new DB2();
             else if  (dbMgrClassName.equals("Oracle"))
                 db = new Oracle();
             else if  (dbMgrClassName.equals("SQLServer"))
                 db = new SQLServer();
             else  { // handle unrecognized
                 Class<?> k = Class.forName(dbMgrClassName);
                 db = (DB) k.newInstance();
             }
             db.init(props);

My question is: Does using if-else statements like the above really 
improve performance? What is the best approach to instantiate classes 
whose type you don't know at compile time?

[toc] | [next] | [standalone]

#5207

On 11/06/2011 1:13 PM, Abu Yahya wrote:
> My question is: Does using if-else statements like the above really
> improve performance? What is the best approach to instantiate classes
> whose type you don't know at compile time?

That code is unlikely to be in some critical inner loop, so any 
efficiency gains would be marginal. Your original solution requires no 
change if the possible classes change and is simpler to understand, each 
of which on its own wins out over marginal gains in efficiency.

[toc] | [prev] | [next] | [standalone]

#5208

On 11.06.2011 19:13, Abu Yahya wrote:
> I have a class that instantiates a private member based on a value in a
> configuration file.
>
> The value is used to determine the class name.
>
> I initially decided to use code similar to the following:
>
>
> // class name comes from property file
> String dbMgrClassName = props.getProperty("db.manager");
> Class<?> k = Class.forName(dbMgrClassName);
> db = (DB) k.newInstance();
> db.init(props);
>
> However, a colleague pointed out that using "new" is faster than using
> "Class.forName().newInstance()". So, I changed the code to the following:
>
> String dbMgrClassName = props.getProperty("db.manager");
> if (dbMgrClassName.equals("DB2"))
> db = new DB2();
> else if (dbMgrClassName.equals("Oracle"))
> db = new Oracle();
> else if (dbMgrClassName.equals("SQLServer"))
> db = new SQLServer();
> else { // handle unrecognized
> Class<?> k = Class.forName(dbMgrClassName);
> db = (DB) k.newInstance();
> }
> db.init(props);
>
> My question is: Does using if-else statements like the above really
> improve performance? What is the best approach to instantiate classes
> whose type you don't know at compile time?

I would stick with the forName() approach.  If performance is critical 
then I would define an interface for the factory method and configure 
the name of a class which much implement this interface.  Then you need 
forName() only once (for instantiating the factory instance) and can use 
new in factory methods (or do even more fancy things like caching etc.).

Doing if else cascades is certainly the worst thing - not so much 
because of the performance but because of the deficiency that you need 
to touch the code every time you want to add a new class.  With the 
other two approaches you do not have to do that.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#5210

On 6/11/2011 10:49 AM, Robert Klemme wrote:
> On 11.06.2011 19:13, Abu Yahya wrote:
...
>> else { // handle unrecognized
>> Class<?> k = Class.forName(dbMgrClassName);
>> db = (DB) k.newInstance();
>> }
...
> Doing if else cascades is certainly the worst thing - not so much
> because of the performance but because of the deficiency that you need
> to touch the code every time you want to add a new class. With the other
> two approaches you do not have to do that.
...

As coded, the forName code was left in as a fall-through handler, so it
new classes can be handled without touching the code. Of course, that
also means it has all the complications of both the if-else approach and
the forName approach.

Patricia

[toc] | [prev] | [next] | [standalone]

#5215

On 6/11/2011 11:34 PM, Patricia Shanahan wrote:
> On 6/11/2011 10:49 AM, Robert Klemme wrote:
>> On 11.06.2011 19:13, Abu Yahya wrote:
> ...
>>> else { // handle unrecognized
>>> Class<?> k = Class.forName(dbMgrClassName);
>>> db = (DB) k.newInstance();
>>> }
> ...
>> Doing if else cascades is certainly the worst thing - not so much
>> because of the performance but because of the deficiency that you need
>> to touch the code every time you want to add a new class. With the other
>> two approaches you do not have to do that.
> ...
>
> As coded, the forName code was left in as a fall-through handler, so it
> new classes can be handled without touching the code.

That's right.

> Of course, that
> also means it has all the complications of both the if-else approach and
> the forName approach.

The intent was to get the best of both worlds, but I agree it's made it 
less easy to understand.

[toc] | [prev] | [next] | [standalone]

#5233

On 06/11/2011 08:04 PM, Patricia Shanahan wrote:
> On 6/11/2011 10:49 AM, Robert Klemme wrote:
>> On 11.06.2011 19:13, Abu Yahya wrote:
> ...
>>> else { // handle unrecognized
>>> Class<?> k = Class.forName(dbMgrClassName);
>>> db = (DB) k.newInstance();
>>> }
> ...
>> Doing if else cascades is certainly the worst thing - not so much
>> because of the performance but because of the deficiency that you need
>> to touch the code every time you want to add a new class. With the other
>> two approaches you do not have to do that.
> ...
>
> As coded, the forName code was left in as a fall-through handler, so it
> new classes can be handled without touching the code. Of course, that
> also means it has all the complications of both the if-else approach and
> the forName approach.

Thanks for hinting at this detail, Patricia!  Performance of this piece 
of code can vary dramatically with configured class / handler name. 
That adds a level of complication which might make tracking issues 
harder ("It was so fast in our lab, now on production it's awfully slow.").

Also I find the inconsistency about what needs to be configured 
irritating: the string can either be a logical name of a handler *or* a 
class name - and you cannot even distinguish them easily (handler names 
presented so far are also valid class names).  IMHO for this it would be 
better to have two different properties with clear defined precedence 
for logical handler name property.  That would also make it explicit 
that there are two mechanisms involved.  Even though, I still prefer one 
of the two uniform approaches (class name, factory class name).

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#5237

On 6/12/2011 5:05 AM, Robert Klemme wrote:
...
> Thanks for hinting at this detail, Patricia! Performance of this piece
> of code can vary dramatically with configured class / handler name. That
> adds a level of complication which might make tracking issues harder
> ("It was so fast in our lab, now on production it's awfully slow.").
...

Is there really any program that instantiates so many database managers
that the difference between newInstance and constructor, and the
pipeline reloads related to conditional branches, become measurable?

I was concerned about the testing issues. Suppose some future changes
introduce a bug in the fall through path. In order to catch that bug,
there would have to be at least one test that instantiates a database
manager other than the ones that are being handled specifically.

Patricia

[toc] | [prev] | [next] | [standalone]

#5239

On Sun, 12 Jun 2011 07:10:07 -0700, Patricia Shanahan wrote:

> Is there really any program that instantiates so many database managers
> that the difference between newInstance and constructor, and the
> pipeline reloads related to conditional branches, become measurable?
>
Is there actually that much difference? It strikes me that both 'new' and 
Class.forName() are doing essentially the same, namely searching the 
class path for the required class, loading it into the JVM and 
instantiating an object from it. I also wonder if 'new' might not be 
implemented as a wrapper for Class.forName(). It certainly could be done 
that way: both return a class object if they are successful and throw an 
exception if the class can't be found.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#5242

On 06/12/2011 04:37 PM, Martin Gregorie wrote:
> On Sun, 12 Jun 2011 07:10:07 -0700, Patricia Shanahan wrote:
>
>> Is there really any program that instantiates so many database managers
>> that the difference between newInstance and constructor, and the
>> pipeline reloads related to conditional branches, become measurable?
>>
> Is there actually that much difference? It strikes me that both 'new' and
> Class.forName() are doing essentially the same, namely searching the
> class path for the required class, loading it into the JVM and
> instantiating an object from it.

Actually, the code will execute a Class.forName() under the hoods for 
the version with direct instantiation.  There is still a fundamental 
difference though: the solution explicitly using Class.forName() will 
provide the name at runtime while the version with the explicit 
constructor call will have it compiled into the code.  Consequently when 
providing the name at runtime reflection has to be used (which is 
usually a tad slower).

The conceptual difference between providing a type at compile time and 
run time is reflected by the necessity to use reflection (in the dynamic 
case) which defers particular type checks to runtime - which is usually 
significantly slower when done frequently because it has to be done for 
_every_ call.

> I also wonder if 'new' might not be
> implemented as a wrapper for Class.forName(). It certainly could be done
> that way: both return a class object if they are successful and throw an
> exception if the class can't be found.

Class.forName() only yields a class (if successful) while new SomeClass 
yields an instance - so new is more like a wrapper around 
Class.forName().newInstance().  But as I said, there is a fundamental 
conceptual difference between the two.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#5274

On 06/12/2011 12:17 PM, Robert Klemme wrote:
> The conceptual difference between providing a type at compile time and
> run time is reflected by the necessity to use reflection (in the dynamic
> case) which defers particular type checks to runtime - which is usually
> significantly slower when done frequently because it has to be done for
> _every_ call.

One particular difference is that, as new uses a class already in the 
constant pool, the lookup only needs to be done at most once per file, 
since it is otherwise indexed by an integer into a cache. Class.forName 
will have a slightly more expensive lookup, since it needs to index a 
hashtable by a String.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5324

On Jun 12, 7:37 am, Martin Gregorie <mar...@address-in-sig.invalid>
wrote:
> On Sun, 12 Jun 2011 07:10:07 -0700, Patricia Shanahan wrote:
> > Is there really any program that instantiates so many database managers
> > that the difference between newInstance and constructor, and the
> > pipeline reloads related to conditional branches, become measurable?
>
> Is there actually that much difference? It strikes me that both 'new' and
> Class.forName() are doing essentially the same, namely searching the
> class path for the required class, loading it into the JVM and
> instantiating an object from it. I also wonder if 'new' might not be
> implemented as a wrapper for Class.forName(). It certainly could be done
> that way: both return a class object if they are successful and throw an
> exception if the class can't be found.

'new' is not a wrapper for 'Class.forName()' because while 'forName()'
does return a class object, 'new' does not unless the class
instantiated actually is 'Class'.  Since the constructors for 'Class'
are not exposed, that's unlikely.

'newInstance()' is different from 'new' also.  It's invoked
reflectively, i.e., via runtime mechanisms, not via a compiled
constructor invocation as via 'new', and throws different exceptions
from the corresponding constructor.  It's also semantically limited to
no-arg constructors.

'newInstance()' appears in a reflective context which is perforce
going to be slower than compiled-in decisions.  Such a context will
properly appear only when performance is not the overarching concern,
nor readability.

--
Lew

[toc] | [prev] | [next] | [standalone]

#5329

On 15/06/11 14:58, lewbloch wrote:
> 
> 'newInstance()' is different from 'new' also.  It's invoked
> reflectively, i.e., via runtime mechanisms, not via a compiled
> constructor invocation as via 'new', and throws different exceptions
> from the corresponding constructor.  It's also semantically limited to
> no-arg constructors.
> 

There is an alternative to the "simple" Class.newInstance() which allows
constructors with arguments to be used. The
Class.getConstructor(Class...) or Class.getDeclaredConstructor(Class...)
method can be used to obtain other constructors for the class. The
newInstance(Object) method of the returned Constructor can then be used
to get an instance of the class (where obj is actually an Object[]
containing the constructor arguments).

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#5241

On 06/12/2011 04:10 PM, Patricia Shanahan wrote:
> On 6/12/2011 5:05 AM, Robert Klemme wrote:
> ...
>> Thanks for hinting at this detail, Patricia! Performance of this piece
>> of code can vary dramatically with configured class / handler name. That
>> adds a level of complication which might make tracking issues harder
>> ("It was so fast in our lab, now on production it's awfully slow.").
> ...
>
> Is there really any program that instantiates so many database managers
> that the difference between newInstance and constructor, and the
> pipeline reloads related to conditional branches, become measurable?

Only OP knows.  That's why I also suggested to go with Class.forName() 
and only pick a different solution if there really was a performance issue.

> I was concerned about the testing issues. Suppose some future changes
> introduce a bug in the fall through path. In order to catch that bug,
> there would have to be at least one test that instantiates a database
> manager other than the ones that are being handled specifically.

Another bad effect from complexity in the implementation...

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#5216

On 6/11/2011 11:19 PM, Robert Klemme wrote:
> On 11.06.2011 19:13, Abu Yahya wrote:
>> I have a class that instantiates a private member based on a value in a
>> configuration file.
>>
>> The value is used to determine the class name.
>>
>> I initially decided to use code similar to the following:
>>
>>
>> // class name comes from property file
>> String dbMgrClassName = props.getProperty("db.manager");
>> Class<?> k = Class.forName(dbMgrClassName);
>> db = (DB) k.newInstance();
>> db.init(props);
>>
>> However, a colleague pointed out that using "new" is faster than using
>> "Class.forName().newInstance()". So, I changed the code to the following:
>>
>> String dbMgrClassName = props.getProperty("db.manager");
>> if (dbMgrClassName.equals("DB2"))
>> db = new DB2();
>> else if (dbMgrClassName.equals("Oracle"))
>> db = new Oracle();
>> else if (dbMgrClassName.equals("SQLServer"))
>> db = new SQLServer();
>> else { // handle unrecognized
>> Class<?> k = Class.forName(dbMgrClassName);
>> db = (DB) k.newInstance();
>> }
>> db.init(props);
>>
>> My question is: Does using if-else statements like the above really
>> improve performance? What is the best approach to instantiate classes
>> whose type you don't know at compile time?
>
> I would stick with the forName() approach. If performance is critical
> then I would define an interface for the factory method and configure
> the name of a class which much implement this interface. Then you need
> forName() only once (for instantiating the factory instance) and can use
> new in factory methods (or do even more fancy things like caching etc.).

Thanks for your reply, Robert.

Could you give an example of how the factory method might look like?

Thanks in advance!

[toc] | [prev] | [next] | [standalone]

#5221

In article <it0brg$s3t$2@speranza.aioe.org>,
 Abu Yahya <abu_yahya@invalid.com> wrote:

> Could you give an example of how the factory method might look like?

There's some good examples here:

<http://en.wikipedia.org/wiki/Factory_method_pattern>

And in the linked article, "Item 1: Consider static factory methods 
instead of constructors."

<http://drdobbs.com/java/208403883?pgno=1>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#5222

In article <nospam-BA6E1B.15432711062011@news.aioe.org>,
 "John B. Matthews" <nospam@nospam.invalid> wrote:

> There's some

There are some

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#5323

On Jun 11, 12:50 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <nospam-BA6E1B.15432711062...@news.aioe.org>,
>  "John B. Matthews" <nos...@nospam.invalid> wrote:
>
> > There's some
>
> There are some
>
> --
> John B. Matthews
> trashgod at gmail dot com
> <http://sites.google.com/site/drjohnbmatthews>

"There's some [plural] ..." is quite common in idiomatic American.

--
Lew

[toc] | [prev] | [next] | [standalone]

#5337

lewbloch wrote:
> On Jun 11, 12:50 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>> In article <nospam-BA6E1B.15432711062...@news.aioe.org>,
>>  "John B. Matthews" <nos...@nospam.invalid> wrote:
>>
>>> There's some
>> There are some
> 
> "There's some [plural] ..." is quite common in idiomatic American.

True, which is an argument for avoiding it (or correcting it, as John
did in his edit).

Though it's not quite as grating as, say, the use of "would" to
indicate the subjunctive mood. ("If I would have knowed there's some
cupcakes, I would have totally ate them all.")

I've pretty much given up on nominative/objective case of pronouns as
a shibboleth ("between you and I") - I suspect more people in the US
now ignore traditional pronoun case than attempt to apply it - but
attentive writers do still try to watch agreement in number, I think.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5345

On Jun 16, 8:21 am, Michael Wojcik <mwoj...@newsguy.com> wrote:
> lewbloch wrote:
> > On Jun 11, 12:50 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> >> In article <nospam-BA6E1B.15432711062...@news.aioe.org>,
> >>  "John B. Matthews" <nos...@nospam.invalid> wrote:
>
> >>> There's some
> >> There are some
>
> > "There's some [plural] ..." is quite common in idiomatic American.
>
> True, which is an argument for avoiding it (or correcting it, as John
> did in his edit).
>
> Though it's not quite as grating as, say, the use of "would" to
> indicate the subjunctive mood. ("If I would have knowed there's some
> cupcakes, I would have totally ate them all.")
>
> I've pretty much given up on nominative/objective case of pronouns as
> a shibboleth ("between you and I") - I suspect more people in the US
> now ignore traditional pronoun case than attempt to apply it - but
> attentive writers do still try to watch agreement in number, I think.
>

Your comments are appropriate for formal writing.  Usenet is
conversational, ergo one should accept idiomatic expressions.
Otherwise we'd insist that no one use "doubt" to mean a mere question
without suspicion.

I do aver that one should spell nouns, particularly proper nouns,
correctly in technical speech, which this is for all its informality,
and it only makes sense to spell the first-person singular nominative
pronoun in English correctly as it's short enough to remember.

There's some folks even more pedantic than I, apparently.  Welcome to
the club, Michael.

--
Lew

[toc] | [prev] | [next] | [standalone]

#5348

lewbloch wrote:
> 
> There's some folks even more pedantic than I, apparently.  Welcome to
> the club, Michael.

Alas, I am that most unsatisfied of creatures, a pedantic
descriptivist. I am annoyed by awkward constructions but lack the
consolation of labeling them as wrong.

But then I do employ casual constructions and idiomatic expressions in
my writing (and speech) - often even in formal writing, when
appropriate for reasons of style. I was merely agreeing with John's
impulse to correct the agreement in number in his first post.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web