System Timer32

[quraji]

>Requested thread.

Thank ya.

>XD Yea. But it costs nothing to give users the option. The interface is completely the same, meaning no readability difference, and there is no extra code or anything because it is copied in using a module... so...

I think you just wanted the whole package to sound cooler.

 

[Nestharus]

Great job with T32x

 

[Romek]

> Added T32xs module, which is similar to T32x but has .stopPeriodic/.startPeriodic safety
The T32xs module seems to be the one without safety.

 

[quraji]

The T32xs module seems to be the one without safety.

Is that a joke? I don't get it

 

[Romek]

The documentation says that T32xs has additional safety checks which T32x doesn't have.
If you look at the code, it's the opposite.

 

[Viikuna]

One has debug mode debug messages, and other one has some safety boolean check.

Thats the difference. ( You are both right, since both of those have some safety stuff, but different safety stuff )







edit. nuthing here really, I removed this edit stuff, because I completely missed the whole point.

 

[Romek]

My bad.

I saw that the 'non safe' version was littered with debug messages, whereas the 'safe' version wasn't.
J4L should put debug messages into both versions.

 

[Viikuna]

My edit thigny in post up there had that idea, but then I realized that its not needed, because with safety boolean its not an issue and messages are not really needed.

 

[Jesus4Lyf]

>J4L should put debug messages into both versions.
For what? The safe version doesn't need 'em...

The actual point isn't user safety, actually. It's user design. Sometimes it is nice to be able to call .stopPeriodic multiple times (think AIDS structs, you can put the .stopPeriodic in AIDS_onDestroy no matter what that way) without having to code in the boolean manually. I use T32xs in AIDS structs for that reason, basically. I use T32x for things where I usually use to use T32.

Both versions are "safe".

 

[Kenny]

THIS...

IS...

AWESOME!!!

Now, in all seriousness, nice going with the update. Very nice stuff.

 

[quraji]

I kind of want a static .periodic() method.

 

[Jesus4Lyf]

I'm thinking a T32_Add(boolexpr) may be in order. It'd just attach it.

 

[Romek]

Instead of the primary difference between T2x and T32xs being safety, perhaps you could actually document that it's more flexible?
After all, I wouldn't use T32xs because of safety, but rather because I can call stopPeriodic in numerous places.

 

[quraji]

After all, I wouldn't use T32xs because of safety, but rather because I can call stopPeriodic in numerous places.

That is the safety :nuts:

 

[Romek]

I'd say it's more of a 'feature' than 'optional safety'.

 

[quraji]

I guess it is technically a feature, but it's a safety feature. Semantics

 

[Kenny]

It is probably not of much use to many people, but what do you think about making next and prev readonly instead of private? Or maybe make some method operators so we can access them.

That way I could make T32 a requirement for my Meat Hook Spell.

 

[Jesus4Lyf]

Is that so in the struct you can iterate over all "next" structs?
Could be done.

 

[Kenny]

>Is that so in the struct you can iterate over all "next" structs?

Yeah something like that. I just feel that having the actual resource available to use, instead of ripping it off and using it internally, makes more sense.

 

[Jesus4Lyf]

I would need to pay attention to what order the list is in, and make that consistent from the version I expose it...

I'll consider it.

Also, the name "next" and "prev" could conflict with other stuff... <_< any ideas for that issue? Or is that unlikely.