You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After reading: "It makes it obvious to users how the class is used" as an argument on static classes I think the helpers ought to be static.
It would rid us of the ac_helper() function and clean the syntax a little. Also, they don't allow a constructor and have no properties. It's not going to happen.
Should it happen; then the accessor ac_helper() should at least be removed as it couples behaviour of helpers very tightly. If you would want to write a Column Helper ever, which would benefit from an AC_Column object that would not be possible now.
After reading: "It makes it obvious to users how the class is used" as an argument on static classes I think the helpers ought to be static.
It would rid us of the ac_helper() function and clean the syntax a little. Also, they don't allow a constructor and have no properties. It's not going to happen.
Should it happen; then the accessor ac_helper() should at least be removed as it couples behaviour of helpers very tightly. If you would want to write a Column Helper ever, which would benefit from an AC_Column object that would not be possible now.
AC_Helper_String::function
ac_helper()->string->function
We might even consider adding global scope function since those are helpers in general and there is no coherence between many functions.
ac_str_word_count()
ac_array_key_replace()
The text was updated successfully, but these errors were encountered: