(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
include
> the object reference like print to make it more like Java's default
toString
> 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.

+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
> include
>> the object reference like print to make it more like Java's default
> toString
>> 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/

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/

<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
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
> include
> > the object reference like print to make it more like Java's default
> toString
> > 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.
>
>
>
>

"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
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>

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

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
> 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>
>
> It'll go eventually. You can yank it yourself if you want <g>.
>
>