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.

<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).
</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.

On Sat, 03 Apr 2004 10:42:35 -0800, Kris wrote:
> <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).
> </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

Agreed. I don't see a need for a print method in Object, not with toString (which I think is handy). The print method should be removed.

Mike Swieton
__
We owe most of what we know to about one hundred men. We owe most of what we
have suffered to another hundred or so.
	- R. W. Dickson

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:c4n04m$2t7t$1@digitaldaemon.com...
> 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.
>
> <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).
> </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.
>
>

It would seem very easy to add a print(char[] msg) using i/o to stdout or stderr
into the Object and not call in the full printf() support.

In article <c4s61i$1npk$1@digitaldaemon.com>, Ben Hinkle says...
>
>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:c4n04m$2t7t$1@digitaldaemon.com...
>> 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.
>>
>> <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).
>> </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.
>>
>>
>
>

It rather looks like it was added for initial debugging purposes, rather than for any far-reaching metaphysical mindgrok concept ...

How can we persuade Walter to remove this? <g>

- Kris

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

Fair enough. However, the root object should never be bound to some semi-physical manifestation of it's surroundings. By that, I mean it should not expect there to be a console attached to its runtime environment, or *anything* similar. An application developer may choose to bind their objects to environmental considerations at some level, but it shouldn't be forced upon them. Especially at the root level :-)

Conversely; toString() assumes only that it can allocate memory or, perhaps more typically, just return an existing array.

Imagine trying to port (or write) some D code to an environment where there is no console, or any other kind of logging facilities? The first thing you'd have to do is remove Object.print() and modify all the code that used it.

I hope I don't come across as overtly "bullish" on this point.

- Kris


"larry cowan" <larry_member@pathlink.com> wrote in message news:c4s812$1r19$1@digitaldaemon.com...
> It would seem very easy to add a print(char[] msg) using i/o to stdout or
stderr
> into the Object and not call in the full printf() support.
>

Kris wrote:

>Imagine trying to port (or write) some D code to an environment where there
>is no console, or any other kind of logging facilities? The first thing
>you'd have to do is remove Object.print() and modify all the code that used
>it.
>  
>
You'd just re-pipe it to some other output, so you wouldn't need to do any of that.

>I hope I don't come across as overtly "bullish" on this point.
>
>- Kris
>  
>
-- 
-Anderson: http://badmama.com.au/~anderson/

Ah. I meant, no Stdio either: a "thin" environment.

Perhaps I'm steering off the topic, but the most prevalent computer on the planet (by far) is the humble microprocessor. D should not ignore the possibility of being the language-of-choice for such platforms; it's a superior choice over C++, which is used surprisingly often. Sure, the GC might have to be replaced ...

Consider that Gosling (or someone at Sun) understands the importance of embracing that world: Java is impedance-mismatched for mcu-land in many ways, but it's gaining a surprising level of acceptance.

Anyway, the point is that printf() really does not belong in the *root* Object, particularly so because it pulls in so much other support code. I believe that stands regardless of where or how one deploys one's application.

- Kris



"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c4sg9b$27qq$1@digitaldaemon.com...
> You'd just re-pipe it to some other output, so you wouldn't need to do any of that.
>

Kris wrote:

>Anyway, the point is that printf() really does not belong in the *root*
>Object, particularly so because it pulls in so much other support code. I
>believe that stands regardless of where or how one deploys one's
>application.
>
This I agree on.

-- 
-Anderson: http://badmama.com.au/~anderson/

Kris wrote:
> It rather looks like it was added for initial debugging purposes, rather
> than for any far-reaching metaphysical mindgrok concept ...
> 
> How can we persuade Walter to remove this? <g>


If we make enough noise, he'll probably listen to us. I suspect he put it in there for debugging purposes a long time ago and never got around to removing it.

I "vote" we remove printf from the root Object.


Similarly, the .size and .sizeof properties are redundant. One of them has to go (I'm guessing .size will disappear.)


Also, I think in order for D to thrive the C-style casting syntax must be dropped in favor of D's other cast syntax.

d = (int) a;  <-- old C-style (sometimes ambiguous)
d = cast(int) a; <-- D-style (never ambiguous)

(I know the casting has already been discussed, but since there wasn't any controversy, I figured it wouldn't hurt to mention it again. http://www.digitalmars.com/drn-bin/wwwnews?D/25720)

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


-- 
Justin
http://jcc_7.tripod.com/d/