Redundant declarations in interface PConstants

Processing
1

Speaking of which, when are the Processing’s devs gonna remove those 3 redundant declarations for the fields inside the interface PConstants? :stuck_out_tongue:

1 Like
2

Sorry, I meant properties, but I’m not even sure if that works in Java. I’m not a Java geek :slight_smile:

3

Maybe just submit a pull request removing them?

1 Like
4

This a bit of-topic but as you raised it.

PApplet implements PConstants so the constants X, Y and Z are available to the sketch creator. Thus the following sketch will run without problem.

println(X,Y,Z);

it will output 0 1 2

Removing them would any sketches that used them :nerd_face:

5

Well, this tutorial explains the types of variables in Java: :coffee:

That’s why I’ve opened it w/: “Speaking of which…” :sweat_smile:

If I do that, it’s a sure way it’s never gonna happen! :zipper_mouth_face:

6

I said it was off-topic because the fact that they have not been removed from PConstants has nothing to do with the topic under discussion. What has happened is that this discussion has been hijacked and as a moderator you should be trying to stop this. I would be happy if all the replies related to PConstants including mine to be deleted.

1 Like
7

Moved this to a new thread.

It seems to me like the key issues here are:

  1. should this be changed at all?
  2. if it should, what – concretely – would that proposed change look like?
1 Like
8

But it has EVERYTHING to do as a sideline followup of my previous warning:

IMO, a mere sideline comment isn’t enough to make a discussion to become hijacked as you had stated.

This split action was completely over-the-top. But whatever… :man_shrugging:

1 Like
9

Sorry if you didn’t want it split, @GoToLoop. For me I thought there was a conversation that was worth hashing out if there was going to be a proposed change to PConstants that should be submitted as a pull.

If the answer is “no” then we can just let this thread end here – or hide it, if you prefer.

10

It was merely a followup anti-example about using redundant modifiers on an ìnterface`.

My “request” on that was just rhetoric. I know pretty well there’s no chance for that to happen.

1 Like
11

You can’t remove constants without breaking compatibility. Maybe suggest for v4?

I’d argue for always having the redundant modifiers for consistency. This is not an anti-pattern, particularly now with things like private methods on interfaces.

On the other hand, ironically, interfaces for the purpose of providing constants is an anti-pattern. A good candidate for replacing with import static (again in v4+)

12

Although most constants within “PConstants.java” are modified w/ static final, there are also static public final & public final static in some! :crazy_face:

That’s not what I’d call “consistency”, but crazy & useless boilerplate! :clown_face:

1 Like
13

Well, they should all be public static final. But that’s all a really minor issue vs getting rid of PConstants as an interface, which is the real anti pattern! Having type safe constants would also be a massive improvement.

14

I hope you’re aware that would make 99.9% of sketches to stop working, right? :construction_worker_man:

15

It would be source compatible actually. In fact, I’ve already done that and type safe constants (which might break source compatibility very rarely, but are really worth it). But it’s not binary compatible so would have to be done in a future major version and libraries recompiled.

16

Meaning you’ve convert interface PConstants into an enum, is that so?

In order for sketches to directly use such constants, I believe they’d need:
import static processing.core.PConstants.*;

However, the whole Processing library would need to change its API to accept enum PConstants in place of each type of the current interface PConstants!

1 Like
17

Those two things are orthogonal. You could use PConstants as it is now with import static, and something the preprocessor could add to the default imports, and thus be source compatible.

An enum doesn’t solve the issue of type safety. You need an enum (or in a couple of edge cases an interface) for each constant grouping. That way, all the methods that accept a constant show the allowed options in code completion and refuse to compile with an invalid constant. Picking up errors at compile time is much more beginner / user friendly. And still source code compatible, except in rare cases people want to store constants in another field.

My wrapper is at Constants.java for reference.

1 Like