sketch width and height not accessable in classes

[skilfullycurled]

I suspect this might be a side effect of the fact that CS scopes variables so nicely, but in Proessing the sketch width and height given to size() are normally global, therefore they can be used inside of classes like so:

class Square
    @x = width/2
    @y = height/w

This issue is only limited to classes. The following works as expected:

dimensions: ->
    println "#{width}, #{height}"

setup: ->
    size 400, 400

draw: ->
    println "#{width}, #{height}" #prints 400, 400
    dimensions() prints #prints 400,400

It is another issue that is perhaps low on the list because there is a rather simple work around which is to declare width and height as variable before the setup. Still, might be useful in the readme.md.

[fjenett]

So, first off ... in general it's bad style to do that. You should pass these into the constructor or use a setter. Processing "allows" them but that is merely a side effect of any classes in .pde code being Java "inner classes".

Then .. your code is simply wrong as you are setting x and y up as class variables, not instance variables. Look into the XXX_compiled.js that actually runs in the browser and you will see that at the time you are using width and height there setup has not yet been called.

You should instead use a constructor for your class and then it will work fine (still bad style):

dimensions: ->
    println "#{width}, #{height}"

setup: ->
    size 400, 400
    new Square

draw: ->
    @dimensions()

class Square
    constructor: () ->
        @x = width/2
        @y = height/2
        println "#{@x}, #{@y}"

Good style would be:

dimensions: ->
    println "#{width}, #{height}"

setup: ->
    size 400, 400
    new Square width, height

draw: ->
    @dimensions()

class Square
    constructor: (w,h) ->
        @x = w/2
        @y = h/2
        println "#{@x}, #{@y}"

[skilfullycurled]

First. Yes. I forgot to write the constructor. My bad (obviously).

With regard to your first example, sure, in the case you presented you can print the x and y variables. However, I'd say it is far more common that you'd want to actually access those variables in the draw loop, not just print them out in the setup. If I can put aside the correctness for a moment, if you wanted to do the following it would not work.

setup: ->
    size 400, 400
    s = new Square

draw: ->
    println "#{s.x}, #{s.y}"


class Square
    constructor: () ->
        @x = width/2
        @y = height/2

The sketch won't work if you declare the Square object outside of setup (TypeError: Square is not a constructor). And, if you move the Square class above, you're back to where you started.

I agree with you that it might be bad style, but it's a pretty common practice in Processing. Dan Shiffman uses it in his new book and he's been using Processing pretty extensively for a long time. Humble opinion: Right or wrong, people have come to expect this. It's the right of any implementation to be opinionated about usage, but it's nice to have the "gotchas" documented in the readme. Could even be a good way to change the opinions of others.

Again. Many thanks for all of your time. People aren't really using CS on the forums so it's hard for me to clear it with the masses first. I apologize that in some cases the issue has been a result of my not understanding CS over an actual problem with the mode. Please know that it's appreciated.

[fjenett]

So what i do is inject the Processing API into the generated js code for that code to be able to access width / height and the others "just like in Processing". Normally you would need to write "@width". That trick only works if i know beforehand where these are defined and how they are named (in other words not for user code). Look at the compiled js code, there right at the top you can see the whole Processing API. Not pretty but it works.

The problem you are now facing is that you think that this is the way it works for all variables which is not the case. Your "s" variable is only defined in the local scope of the setup function. That is how CS/JS works. If you want it to be part of the whole sketch instance, then you need to define it as an instance variable (this.s) which in CS is "@s". Doing so makes your code work.

[fjenett]

... maybe that was not clear: your whole sketch is a class just like the one you defined. Look at the compiled js code. It's all visible there!

[fjenett]

Like this:

setup: ->
    size 400, 400
    @s = new Square

draw: ->
    println "#{@s.x}, #{@s.y}"


class Square
    constructor: () ->
        @x = width/2
        @y = height/2

[skilfullycurled]

Ah haaaaaa...okay. Remember in the other issue when you asked if it was crystal clear? Well, turned out it was still cloudy and hadn't been filtered though my brain. You've suggested before that I look at the JavaScript that it spits out and I apologize for not doing that sooner. Viewing that, plus your explanation helped to solidify a few things. I had suspected the whole sketch was a class because the draw and setup were in object notation (setup: ->) and not declared functions (setup = ->). I did not know, that the entire Processing API isn't available until after setup() is run. Do I have that right?

I'm not sure if I have the reasoning correct but it seems like whatever we're discussing here is responsible for the fact that even a simple math function won't work when used before setup.

#c = cos PI/2        #forget it
#@c = cos PI/2    #can't get there from here

setup: ->
    size 200,200
    noLoop()
    @c = cos PI/2 #yay! woot \0/

draw: ->
    #won't work
    println z 

    #will work only if declared in setup
    println @c #prints 6.123233995736766e-17

Tell me if you agree with the following: the best practice for using CS Mode when you want to use anything "globally" (relative to your sketch) and/or created with the Processing API, is in the setup function prefixed by @ (this). This is because the API is injected in the setup function.

Humble Opinion: This is definitely worth explaining this the readme. I would say it's practically mantra in Processing to declare at the top, assign/create in setup, and access in draw. You would never think to do both inside setup() because it wouldn't be available to you later. This is the way it must be done in the IDE for both Java and JS mode. It might be obvious if you are a seasoned in CS but I think there will be an expectation that the IDE will work similarly across all modes.

Without this understanding, I would have been filing an issue for every aspect of the API. Next up was PVectors!

As always, many thanks.

Benjamin

[fjenett]

Hm, hm .. you are probably right. There are several aspects here that need to be covered:

readme update
--> yes totally

Processing API constants and Processing API static functions
--> should be available outside setup and before setup is called

more CS language specific examples
--> to explain and show best practices

Gonna reopen but don't hold your breath as i'm drowning in work atm.

Thanks!

[skilfullycurled]

Hey. At your leisure. I appear to be the only person who doesn't understand this, or am the only person using the mode. It's all documented in the conversation, and now I understand it so...all good?

Processing API constants and Processing API static functions
--> should be available outside setup and before setup is called

not necessarily. if you truly believe that the best way to do it is in the setup function, then note that in the readme. it's a simple enough thing to remember and i assume it seems like it works everytime. so once you've learned it, you're good to go. If it doesn't matter and the aim is to make the mode as much like P/PJS mode, then that would be a nice enhancement.

Can't say enough. So grateful. I'm sure you are often drowning in work!