"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-625719.08263725022004@news.povray.org...
> In article <403c3ec3$1@news.povray.org>,
>  "Hughes, B." <omn### [at] charternet> wrote:
>
> > Where MySphere remains defined but gets additional info attached to it.
Or
> > all at once:
> >
> > ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}
>
> def ThisSphere = sphere {<1,2,3>, 1 pigment {<0.1,0.2,0.3,1,0>}}
>
> The dot syntax is just about always used for accessing parts of an
> object, not for creating one. Like vector .x, .y, .z, or color .red,
> .green, etc.

Ahh yes, thanks for that clarification. I suspected as much but it was
looking to me like everything was to be built in the same way as accessing
it later.

> > Then raytraced when only the name stands alone:
> >
> > ThisSphere
>
> There's several ways adding the object to the scene could be handled,
> this is one way.

I like not having to use object {ThisSphere}, so this is a good thing I
think. Minimized scripting in the same vein as not needing parent wrappers,
which I believe you actually mentioned back in the thread someplace, could
be nice. Maybe not clear until learning what's what, but easier to write.

> > And so it's difficult to think of doing this for evermore complicated
> > things. Am I on the wrong track to believe this way?
>
> Yes. You're assuming you would have to do everything in a much more
> complex fashion, this is not the case. The final result could be very
> similar to the current POV language in general use.

Okay. But, admittedly, it would still become more code-like for the writers
of it. Yet, presumably, easier to use the result. Regardless, I think all
this will come down to a widened dividing line between casual artists and
data-crunchers. Since no one knows the future for certain it could go either
way, good or bad thing. Maybe no worse than other changes had been. Hmmm...
That's a statement not to be taken too lightly. The halo, semicolons,
patterns... sounds ultra mild compared to most of the talk in this thread.
;-)

Bob H.

Post a reply to this message

In article <403d0e51$1@news.povray.org>,
 "Hughes, B." <omn### [at] charternet> wrote:

> Ahh yes, thanks for that clarification. I suspected as much but it was
> looking to me like everything was to be built in the same way as accessing
> it later.

You could create a language in such a way, but it would be quite 
strange...actually, JavaScript is a little similar. But none of the 
syntaxes I've seen suggested for POV would do it this way.


> I like not having to use object {ThisSphere}, so this is a good thing I
> think. Minimized scripting in the same vein as not needing parent wrappers,
> which I believe you actually mentioned back in the thread someplace, could
> be nice. Maybe not clear until learning what's what, but easier to write.

I think you might be referring to my "#declare MyObj = object {MyObj 
translate...}" example. I would actually prefer some kind of wrapper, 
though maybe not of that exact form. Something like:

scene {
    MyObj;
    AnotherObj;
    AndAnotherOne;
    SomeProcedureThatReturnsAnObject();
    ObjectMaker.MakeAnObject();
}

Basically, any statement that results in an object puts an object into 
the scene when used within a scene {} block. Outside a scene block, the 
object just gets ignored. Otherwise you'll run into annoyances when you 
call something that returns an object that is only desired some of the 
time. Say you have a procedure that does something to an object and 
returns that object for convenience, but you sometimes need to call it 
but don't need the returned object. Without the scene{} block 
restriction, you'd have to do something like declare a dummy variable 
just to hold the object you don't want...annoying.
I also think it makes things a bit clearer to have some kind of wrapper 
for the object name.


> > Yes. You're assuming you would have to do everything in a much more
> > complex fashion, this is not the case. The final result could be very
> > similar to the current POV language in general use.
> 
> Okay. But, admittedly, it would still become more code-like for the writers
> of it. Yet, presumably, easier to use the result.

Well, it won't make the internals of a lens flare system any easier for 
non-coders to understand, but it will make it easier for them to use it. 
Objects are typically seen as "black boxes", they can be very complex 
inside but nobody has to care about that, they only use the stuff on the 
outside.


> Regardless, I think all this will come down to a widened dividing 
> line between casual artists and data-crunchers.

I don't think so. It will mean more is possible entirely within POV 
script, so the "data crunchers" won't have to go to external tools, and 
the casual users have a much shorter distance to go before they can 
understand and create similar things. POV-artists and POV-coders, rather 
than POV-artists and C++/Java/Python-coders-who-export-POV-code.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-6C16F7.17001225022004@news.povray.org...
> In article <403d0e51$1@news.povray.org>,
>  "Hughes, B." <omn### [at] charternet> wrote:
>
> > I like not having to use object {ThisSphere}
>
> I think you might be referring to my "#declare MyObj = object {MyObj
> translate...}" example. I would actually prefer some kind of wrapper,
> though maybe not of that exact form. Something like:
>
> scene {
>     MyObj;
>     AnotherObj;
>     AndAnotherOne;
>     SomeProcedureThatReturnsAnObject();
>     ObjectMaker.MakeAnObject();
> }
>
> Basically, any statement that results in an object puts an object into
> the scene when used within a scene {} block. Outside a scene block, the
> object just gets ignored. Otherwise you'll run into annoyances when you
> call something that returns an object that is only desired some of the
> time.
---snip---
> I also think it makes things a bit clearer to have some kind of wrapper
> for the object name.

Yes, I can see the reasoning here. This whole discussion, of what I didn't
skip anyway, was causing my mind to wander and think about it being possible
to write a piece of the SDL likened to the way a #macro() is now but with
far more interaction. And so, in that way, I thought of it as allowing for
subsets of a new kind of SDL which are callable at any time; same as the
program code itself. Maybe the term would be soft-code rather than
hard-code. From that idea I could see it as not needing every designation
such as would be if a material{} had to always be written out in full for a
simple color.

Anyway, I think I'm understanding it better now that I spoke up. It surely
is of the realm of programming before the final usage could come into play.
But I feel I've backtracked here by rehashing what's probably already been
said.

Bob H.

Post a reply to this message

In article <cjameshuff-DF3DAB.08451225022004@news.povray.org>,
 Christopher James Huff <cja### [at] earthlinknet> wrote:

> > It can't even theoretically
> > check this at linking time because some code in a dynamic library (which
> > may change in the future) may implement that virtual function.
> 
> C++ doesn't play particularly well with dynamic linking. C++ RTTI and 
> virtual functions can cause many problems with it.

I forgot to mention it, but you might want to look up "fragile base 
classes".

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:403c6c39@news.povray.org...
>   That's a big like claiming that std::sort() always takes the same length
> of time (even if you use it only with one type of parameters).

What I mean is that "+" should always take the same length of time, and should
not be confused with something that will take a different length of time.

Though I'm tired of repeating myself. If you disagree with me that's fine, but
you still seem to misunderstand what I'm saying, and I've got tired of
explaining.

Honestly I was just trying to point out we don't do this in the games industry,
not start a debate based on confusion...

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> And that's where you keep going off topic. We're not talking about Java 
> interfaces, we're talking about interfaces.

  So what's the difference between Java interfaces, your interfaces and
abstract classes?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> > > It can't even theoretically
> > > check this at linking time because some code in a dynamic library (which
> > > may change in the future) may implement that virtual function.
> > 
> > C++ doesn't play particularly well with dynamic linking. C++ RTTI and 
> > virtual functions can cause many problems with it.

> I forgot to mention it, but you might want to look up "fragile base 
> classes".

  But I was not talking about changing base classes. I was talking about
changing derived classes. There's a big difference.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I mean, Java interfaces are specific to Java, generic interfaces aren't, 
> and abstract classes can actually have code and stuff in them and Java 
> doesn't support that. Why do you ask?

  That doesn't really tell what these "generic interfaces" are, and how
they are different from either abstract classes or Java interfaces.
  I know the latter two, but I have no idea what these "generic interfaces"
could be.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> They're interfaces that can't have code and aren't specific to Java. 

  That's like saying that a "generic int" is a variable which can have
an integer value and is not related to C.
  That statement doesn't make any sense.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> For example, one could ask "Should a generic int be limited in size in a 
> new programming language? If so, should a generic int throw an error on 
> overflow or just silently wrap around?" You're not asking specifically 
> in the context of C, for which the decision has already been made. 
> You're asking in the context of a new language which hasn't been 
> invented yet.

  The difference is that basically you are saying that these "generic
interfaces" are identical to Java interfaces, but have nothing to do
with Java interfaces...

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message