PB5.60 please rename Event()

[PMV]

Why Fred? Every PB-Function collides with module-function-names ...
so how should we call our event-procedures now?

Imagin a custom window-module for screens ... you want to have
an "event"-procedure. The logical step is to call it "Event()" and use
Window::Event() to call the function out of the module. That's not
possible anymore. Adding the module name to the function to get it
unique ... "WindowEvent" or "EventWindow"? Ugly. And it's already
a PB functions, too ... so it wouldn't work. Now? There are plenty
of possibilities like Window::MakeEvent() or Window::DoEvent().
But why i'm forced to use ugly names? Btw. the time i will need to
think about another name ... and rename everything is stolen time
i will never get back ... yes, i really dislike it, PB-functions collide
with module-procedure-names and this reminds me.

... i want to have my module-function-names as simple as possible.
With modules, it is possible to make code as clean as possible ...
but why do you need to use generic names for functions, that will
block us from using this to name a module-procedure properly?



sorry for my feelings ...
btw. this request is just asking to rename this "Event()" function
before stable release.

MFG PMV

[Fred]

I understand your concern, but the fact is PB use a lot of common name for its commandset. You can check the list here http://www.purebasic.com/documentation/ ... index.html and you will see a lot, we won't prefix them all as it will make main code less readable

[fsw]

The best would be to change the new PB command Event() to GetEvent() as it shows what actually happens.
It gets the next event in the queue...

This would also be in line with PostEvent() BindEvent() etc.

IMHO GetEvent() should be used instead of Event().

Fred, please consider it.
Thank you for reading.

[Fred]

Well Event() is in line with EventWindow(), EventMenu() etc., it's not GetWindowEvent()

[fsw]

Ok.
What about GetNextEvent().
Or only NextEvent()

If the command should start with Event what about:
EventFromApp()
EventFromQueue()
EventQueue()
EventFromApplicationQueue()

You get the idea...

[skywalk]

I think Event() = EventNow() and not NextEvent()?

[fsw]

I think Event() = EventNow() and not NextEvent()?

Are you saying that Event() is not getting the next event in the queue?

BTW: didn't play with the beta version, so I didn't test it yet...

[fryquez]

Instead of renaming, improve modules

[skywalk]

Return the current event. It is the same value returned by WindowEvent() and WaitWindowEvent(), it is mainly useful when using a callback to determine which event triggered it.

And I thought only control flow keywords(for, if, and, next, etc) were blocked from Module variables? I thought the point of Modules allowed isolating functional names?

[netmaestro]

Event() is best and conforms to PB's established nomenclature.

[Fred]

Return the current event. It is the same value returned by WindowEvent() and WaitWindowEvent(), it is mainly useful when using a callback to determine which event triggered it.

And I thought only control flow keywords(for, if, and, next, etc) were blocked from Module variables? I thought the point of Modules allowed isolating functional names?

I think he talks about module procedure name, which can't clash with internal keyword (or you can't call internal keyword anymore).

[mestnyi]

Well Event() is in line with EventWindow(), EventMenu() etc., it's not GetWindowEvent()

I also think Fred and netmaestro is right.

this request is just asking to rename this "Event()" function

But i agree with PMV and fsw
Therefore, I propose rename "Event()" to "EventHandle()"
But it would be even better if Fred would do so.

Code: Select all

Procedure WindowHandler(Event)
  
  Select Event
    Case #PB_Event_LeftClick
      Debug "Click event on window #" + EventWindow()
    
    Case #PB_Event_SizeWindow
      Debug "Size event on window #" + EventWindow()
    
  EndSelect
  
EndProcedure
    
  OpenWindow(0, 100, 100, 200, 200, "event test", #PB_Window_SizeGadget | #PB_Window_SystemMenu)
  
  BindEvent(#PB_Event_SizeWindow, @WindowHandler())
  BindEvent(#PB_Event_LeftClick, @WindowHandler())
  
  Repeat
    Event = WaitWindowEvent()
  Until Event = #PB_Event_CloseWindow

[PMV]

I understand your concern, but the fact is PB use a lot of common name for its commandset. You can check the list here http://www.purebasic.com/documentation/ ... index.html and you will see a lot, we won't prefix them all as it will make main code less readable

That's why it's hurting so much. And that's why many already dislike the fact,
that modules collide with PB-function-names.

What a pity. But maybe one day there will be a version where there is an
option that changes the behavior. For example, i could think about a
checkbox that enables PB-functions to be called like modules. That
way it is only optional and the current behavior is preserved. But to
have the option to call PB-function if they were inside a module and
so have their own namespace, i would love to use it. Even though i
would have to update all calls to PB-functions with a prefix like "PB::".
It would help the readability of own modules very much.

Looking forward to this.

MFG PMV

[netmaestro]

You choose your own module function names so I don't see how collisions with the PB commandset could be an issue.

[fryquez]

You choose your own module function names so I don't see how collisions with the PB commandset could be an issue.

Well, the PB commandset grows with every version, and both the PB devs and the guys that writes modules, prefer easy function names.
So there will always be a big risk for collisions.

And how the hell wants to always change their module function names?