www.digitalmars.com         C & C++   DMDScript  

D - the root Object, and printf

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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.
Apr 03 2004
next sibling parent Mike Swieton <mike swieton.net> writes:
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
Apr 03 2004
prev sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
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.
Apr 05 2004
next sibling parent reply larry cowan <larry_member pathlink.com> writes:
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.
Apr 05 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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.
Apr 05 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Apr 05 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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.
Apr 05 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Apr 05 2004
prev sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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.
Apr 05 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Apr 05 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J C Calvarese wrote:


 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)


Good idea. I think it would be a good idea to remove these depreciated 
features ASAP, so software that is already written can be readied more 
quickly for 1.0.  You don't want to release 1.0 and have nothing working 
properly with it.

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 05 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Good idea. I think it would be a good idea to remove these depreciated 
features ASAP, so software that is already written can be readied more 
quickly for 1.0.  You don't want to release 1.0 and have nothing working 
properly with it.


I was just thinking the same thing a few days ago - in particular
the template "instance" construct has been deprecated in favor
of !. We need at least one release that rips out these crufty
features so that 1.0 is as clean as possible. The documentation
doesn't list it anymore but "instance" is still a keyword.

-Ben
Apr 05 2004
parent reply C <dont respond.com> writes:
I agree on both points.  If were going to keep 1.0 as the standard for a=
 =

while then lets streamline it at the risk of losing some backward =

compatility.

C

On Mon, 05 Apr 2004 19:57:33 -0400, Ben Hinkle <bhinkle4 juno.com> wrote=
:


 Good idea. I think it would be a good idea to remove these depreciate=




d

 features ASAP, so software that is already written can be readied mor=




e

 quickly for 1.0.  You don't want to release 1.0 and have nothing work=




ing

 properly with it.


 I was just thinking the same thing a few days ago - in particular
 the template "instance" construct has been deprecated in favor
 of !. We need at least one release that rips out these crufty
 features so that 1.0 is as clean as possible. The documentation
 doesn't list it anymore but "instance" is still a keyword.

 -Ben




-- =

D Newsgroup.
Apr 06 2004
parent reply "Phill" <phill pacific.net.au> writes:
"C" <dont respond.com> wrote in message news:opr51ti2oxehmtou localhost...
I agree on both points.  If were going to keep 1.0 as the standard for a
while then lets streamline it at the risk of losing some backward
compatility.

1.0?
How close do you think 1.0 is?

As the days go by, it seems further away
each day. :o(

Phill.


C

On Mon, 05 Apr 2004 19:57:33 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:


 Good idea. I think it would be a good idea to remove these depreciated
 features ASAP, so software that is already written can be readied more
 quickly for 1.0.  You don't want to release 1.0 and have nothing working
 properly with it.


 I was just thinking the same thing a few days ago - in particular
 the template "instance" construct has been deprecated in favor
 of !. We need at least one release that rips out these crufty
 features so that 1.0 is as clean as possible. The documentation
 doesn't list it anymore but "instance" is still a keyword.

 -Ben




--
D Newsgroup.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
Apr 07 2004
parent reply Brad Anderson <brad dsource.dot.org> writes:
Phill wrote:

 "C" <dont respond.com> wrote in message news:opr51ti2oxehmtou localhost...
 I agree on both points.  If were going to keep 1.0 as the standard for a
 while then lets streamline it at the risk of losing some backward
 compatility.
 
 1.0?
 How close do you think 1.0 is?
 


At SDWest (3/17), Walter said he'd like to get it out by the end of the 
month.  That didn't happen, but I'd rather see the delay and have him 
get some work done on Interfaces and other bugs than to rush out 1.0. 
He's resisted so far, so hopefully he can tidy it up in the first half 
of the year...

BA
Apr 07 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Brad Anderson wrote:


 At SDWest (3/17), Walter said he'd like to get it out by the end of 
 the month.  That didn't happen, but I'd rather see the delay and have 
 him get some work done on Interfaces and other bugs than to rush out 
 1.0. He's resisted so far, so hopefully he can tidy it up in the first 
 half of the year...

 BA


Yes I too would rather a delay of a few months then a rushed product.  
Of course there will probably always be some problem issue popping up 
with D that needs to be *fixed* and these may even be more important 
then the com issue.  If W delayed 1.0 D for every one, it would never 
get there.

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 07 2004
parent reply "Phill" <phill pacific.net.au> writes:
For that matter id rather him delay it for  6 months,
or even more, than to present an inferior language.

Nothing but the best for D, is what id like to see.

Phill.


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c51l6a$v1i$1 digitaldaemon.com...

 Brad Anderson wrote:


 At SDWest (3/17), Walter said he'd like to get it out by the end of
 the month.  That didn't happen, but I'd rather see the delay and have
 him get some work done on Interfaces and other bugs than to rush out
 1.0. He's resisted so far, so hopefully he can tidy it up in the first
 half of the year...

 BA


 Yes I too would rather a delay of a few months then a rushed product.
 Of course there will probably always be some problem issue popping up
 with D that needs to be *fixed* and these may even be more important
 then the com issue.  If W delayed 1.0 D for every one, it would never
 get there.

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



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
Apr 08 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Phill" <phill pacific.net.au> wrote:


 Nothing but the best for D, is what id like to see.


LOL. You're a poet and don't know it :-)

Actually, I'd like to see that too, but the recent interface discussion 
worries me, to be honest. I hadn't gotten into using them yet with D, but 
to learn that the design catered to COM, of all things, kinda shook me up.  
It has always been my philosophy that you NEVER cripple a design for old, 
obsolete, or deficient technologies -- you bring the older technology into 
line in whatever way possible, without affecting new work. If that means 
special pragmas or keywords, fine, but do NOT hinder new development. I 
certainly hope Walter takes the opinions voices here recently into account.

Anyway, while it's been fun checking out D, I need to get back to real 
work, alas, with C++. After this project, maybe I'll have time to come back 
and see how these issues have turned out, and hopefully see a 1.0 release. 
Go for it, Walter!

-- 
dave
Apr 08 2004
parent "Phill" <phill pacific.net.au> writes:
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94C565EDC2E19dsiebersbc 63.105.9.61...

 "Phill" <phill pacific.net.au> wrote:


 Nothing but the best for D, is what id like to see.


 LOL. You're a poet and don't know it :-)


Your right, I didnt know it(or notice it) hahaha.

Phill.


 Actually, I'd like to see that too, but the recent interface discussion
 worries me, to be honest. I hadn't gotten into using them yet with D, but
 to learn that the design catered to COM, of all things, kinda shook me up.
 It has always been my philosophy that you NEVER cripple a design for old,
 obsolete, or deficient technologies -- you bring the older technology into
 line in whatever way possible, without affecting new work. If that means
 special pragmas or keywords, fine, but do NOT hinder new development. I
 certainly hope Walter takes the opinions voices here recently into


account.

 Anyway, while it's been fun checking out D, I need to get back to real
 work, alas, with C++. After this project, maybe I'll have time to come


back

 and see how these issues have turned out, and hopefully see a 1.0 release.
 Go for it, Walter!

 --
 dave



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
Apr 08 2004