www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Repost: the root-object and Printf

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
(Reposting this from the old NG, so that it doesn't get "lost")

I vaguely recall reading in the "D Programming Manual" that one should
strive to limit dependencies between modules (paraphrased from memory),
presumably to reduce code-bloat (and, uh, forward references :-)

I don't think many would really disagree with that as an underlying
principle. Therefore, I find it somewhat disconcerting that the root Object
imports and uses printf() ... printf, by it's very nature, has to then pull
in a raft of floating-point library support.

<mild-rant>
This may be a small point, but Object.printf() really needs to be removed
IMHO. Surely the method Object.toString() is present for related, if not
identical, usage?  If someone *really* needs a printf() in a root class, or
to differentiate between toString() and print(), they can derive their own
root class (PrintfObject) and be done with it. That's hardly the majority
case, methinks.

OTOH: If there really is a good reason to differentiate, then I suggest the
base-class implementation should be present for overloading purposes only
(does nothing itself).
</mild-rant>

Either way I think it's time to practice what is preached: let's eliminate
Object.print (or minimally the printf call; for v1.0) before a lot of people
do something silly, such as writing code that depends on it <g>

- Kris


p.s.  Note that since the gcc backend generates code for microcontrollers,
it's conceivable that D might be used for such applications ... printf is a
typically a big no-no for such things.


  <<<<<<<<<<<<<<<<<<




















FOLLOW UP POST IDENTIFYING root.Print USAGE: "Ben Hinkle" <bhinkle4 juno.com> wrote in message news:c4s61i$1npk$1 digitaldaemon.com...
 I agree. It seems like Object.print is redundant. A lone toString is fine
 even though it would allocate a string. Also I think toString should

 the object reference like print to make it more like Java's default

 for java.lang.Object.

 Grepping the code base print() is used in various try-catch
 or debug blocks:

 phobos/internal/dmain2.d:  o.print();
 phobos/internal/gc/gcx.d:              current.data[i].print();
 phobos/internal/gc/gcx.d:              current.data[i].print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/thread.d:           o.print();
 phobos/std/thread.d:           o.print();

 It doesn't look like a big deal to remove it.

May 24 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
+1 I agree whole-heartedly.

On Mon, 24 May 2004 10:21:39 -0700, Kris 
<someidiot earthlink.dot.dot.dot.net> wrote:

 (Reposting this from the old NG, so that it doesn't get "lost")

 I vaguely recall reading in the "D Programming Manual" that one should
 strive to limit dependencies between modules (paraphrased from memory),
 presumably to reduce code-bloat (and, uh, forward references :-)

 I don't think many would really disagree with that as an underlying
 principle. Therefore, I find it somewhat disconcerting that the root 
 Object
 imports and uses printf() ... printf, by it's very nature, has to then 
 pull
 in a raft of floating-point library support.

 <mild-rant>
 This may be a small point, but Object.printf() really needs to be removed
 IMHO. Surely the method Object.toString() is present for related, if not
 identical, usage?  If someone *really* needs a printf() in a root class, 
 or
 to differentiate between toString() and print(), they can derive their 
 own
 root class (PrintfObject) and be done with it. That's hardly the majority
 case, methinks.

 OTOH: If there really is a good reason to differentiate, then I suggest 
 the
 base-class implementation should be present for overloading purposes only
 (does nothing itself).
 </mild-rant>

 Either way I think it's time to practice what is preached: let's 
 eliminate
 Object.print (or minimally the printf call; for v1.0) before a lot of 
 people
 do something silly, such as writing code that depends on it <g>

 - Kris


 p.s.  Note that since the gcc backend generates code for 
 microcontrollers,
 it's conceivable that D might be used for such applications ... printf 
 is a
 typically a big no-no for such things.


  <<<<<<<<<<<<<<<<<<




















FOLLOW UP POST IDENTIFYING root.Print USAGE: "Ben Hinkle" <bhinkle4 juno.com> wrote in message news:c4s61i$1npk$1 digitaldaemon.com...
 I agree. It seems like Object.print is redundant. A lone toString is 
 fine
 even though it would allocate a string. Also I think toString should

 the object reference like print to make it more like Java's default

 for java.lang.Object.

 Grepping the code base print() is used in various try-catch
 or debug blocks:

 phobos/internal/dmain2.d:  o.print();
 phobos/internal/gc/gcx.d:              current.data[i].print();
 phobos/internal/gc/gcx.d:              current.data[i].print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/thread.d:           o.print();
 phobos/std/thread.d:           o.print();

 It doesn't look like a big deal to remove it.


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 24 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Kris wrote:
 (Reposting this from the old NG, so that it doesn't get "lost")
 
 I vaguely recall reading in the "D Programming Manual" that one should
 strive to limit dependencies between modules (paraphrased from memory),
 presumably to reduce code-bloat (and, uh, forward references :-)
 
 I don't think many would really disagree with that as an underlying
 principle. Therefore, I find it somewhat disconcerting that the root Object
 imports and uses printf() ... printf, by it's very nature, has to then pull
 in a raft of floating-point library support.
 
 <mild-rant>
 This may be a small point, but Object.printf() really needs to be removed
 IMHO. Surely the method Object.toString() is present for related, if not
 identical, usage?  If someone *really* needs a printf() in a root class, or
 to differentiate between toString() and print(), they can derive their own
 root class (PrintfObject) and be done with it. That's hardly the majority
 case, methinks.
 
 OTOH: If there really is a good reason to differentiate, then I suggest the
 base-class implementation should be present for overloading purposes only
 (does nothing itself).
 </mild-rant>
 
 Either way I think it's time to practice what is preached: let's eliminate
 Object.print (or minimally the printf call; for v1.0) before a lot of people
 do something silly, such as writing code that depends on it <g>
 
 - Kris

I agree.
 ...

-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 24 2004
prev sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
<grumble>

Don't want to act like a wee dog nipping at your heels Walter, but printf()
is *still* linked via object.d ... There was a mention of it being changed
in v0.92, but apparently that was for something else instead. I also note
that printf() is invoked from Exception too (in the same file) ...
p-l-e-a-s-e ?

</grumble>


"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c8tate$30cu$1 digitaldaemon.com...
 (Reposting this from the old NG, so that it doesn't get "lost")

 I vaguely recall reading in the "D Programming Manual" that one should
 strive to limit dependencies between modules (paraphrased from memory),
 presumably to reduce code-bloat (and, uh, forward references :-)

 I don't think many would really disagree with that as an underlying
 principle. Therefore, I find it somewhat disconcerting that the root

 imports and uses printf() ... printf, by it's very nature, has to then

 in a raft of floating-point library support.

 <mild-rant>
 This may be a small point, but Object.printf() really needs to be removed
 IMHO. Surely the method Object.toString() is present for related, if not
 identical, usage?  If someone *really* needs a printf() in a root class,

 to differentiate between toString() and print(), they can derive their own
 root class (PrintfObject) and be done with it. That's hardly the majority
 case, methinks.

 OTOH: If there really is a good reason to differentiate, then I suggest

 base-class implementation should be present for overloading purposes only
 (does nothing itself).
 </mild-rant>

 Either way I think it's time to practice what is preached: let's eliminate
 Object.print (or minimally the printf call; for v1.0) before a lot of

 do something silly, such as writing code that depends on it <g>

 - Kris


 p.s.  Note that since the gcc backend generates code for microcontrollers,
 it's conceivable that D might be used for such applications ... printf is

 typically a big no-no for such things.


  <<<<<<<<<<<<<<<<<<




















FOLLOW UP POST IDENTIFYING root.Print USAGE: "Ben Hinkle" <bhinkle4 juno.com> wrote in message news:c4s61i$1npk$1 digitaldaemon.com...
 I agree. It seems like Object.print is redundant. A lone toString is


 even though it would allocate a string. Also I think toString should

 the object reference like print to make it more like Java's default

 for java.lang.Object.

 Grepping the code base print() is used in various try-catch
 or debug blocks:

 phobos/internal/dmain2.d:  o.print();
 phobos/internal/gc/gcx.d:              current.data[i].print();
 phobos/internal/gc/gcx.d:              current.data[i].print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/conv.d:     debug(conv) e.print();
 phobos/std/thread.d:           o.print();
 phobos/std/thread.d:           o.print();

 It doesn't look like a big deal to remove it.


Jul 08 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:cclcb7$18dh$1 digitaldaemon.com...
 <grumble>

 Don't want to act like a wee dog nipping at your heels Walter, but

 is *still* linked via object.d ... There was a mention of it being changed
 in v0.92, but apparently that was for something else instead. I also note
 that printf() is invoked from Exception too (in the same file) ...
 p-l-e-a-s-e ?

 </grumble>

It'll go eventually. You can yank it yourself if you want <g>.
Jul 09 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
manana, manana ... wanted to ensure it was still on the list <g>

"Walter" <newshound digitalmars.com> wrote in message
news:ccmgf9$2usm$2 digitaldaemon.com...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:cclcb7$18dh$1 digitaldaemon.com...
 <grumble>

 Don't want to act like a wee dog nipping at your heels Walter, but

 is *still* linked via object.d ... There was a mention of it being


 in v0.92, but apparently that was for something else instead. I also


 that printf() is invoked from Exception too (in the same file) ...
 p-l-e-a-s-e ?

 </grumble>

It'll go eventually. You can yank it yourself if you want <g>.

Jul 09 2004