Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$this->options in class_parser.php #880

Closed
Sama34 opened this issue Jul 5, 2014 · 9 comments
Closed

$this->options in class_parser.php #880

Sama34 opened this issue Jul 5, 2014 · 9 comments
Assignees
Labels
b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled t:enhancement Type: Enhancement. Contains minor improvements
Milestone

Comments

@Sama34
Copy link
Contributor

Sama34 commented Jul 5, 2014

Currently in class_parser.php we use the $options array instead of $this->options which is preferable.

I have tested many plug-ins in the past and I doubt any will be affected by this change. MyBB itself shouldn't be.

Reference: http://community.mybb.com/thread-57997.html

@Sama34 Sama34 added this to the 1.8 Beta 3 milestone Jul 5, 2014
@Sama34 Sama34 self-assigned this Jul 5, 2014
Sama34 pushed a commit that referenced this issue Jul 5, 2014
@Sama34
Copy link
Contributor Author

Sama34 commented Jul 5, 2014

    /**
     * Options for this parsed message (Private - set by parse_message argument)
     *
     * @access public
     * @var array
     */
    public $options;

Is it me being bad at English or is there a mistake?

Also, any reason for the cache_mycode(), cache_smilies(), and cache_badwords() methods to remain private?

@mybb/developers

@euantorano
Copy link
Member

I asusme you are referencing the comment (Private - set by parse_message argument) when the parameter is actually public? If so, that's probably not a big deal - leave it public but change the comment. There may be plugins relying on it being public. I haven't seen any, but it's not a risk we can take.

@Sama34
Copy link
Contributor Author

Sama34 commented Jul 6, 2014

Yes I meant the comment, IIRC it was private and was changed at some point for that reason.

But is there any reason for the before mentioned methods to remain private? I can think of I least once where I tried to use those but couldn't.

@euantorano
Copy link
Member

I don't see why making them public would hurt. If they could be useful outside the class, go ahead. There's no cost to doing it 😄

@Sama34
Copy link
Contributor Author

Sama34 commented Jul 10, 2014

If no one objects I will make them public and then close this then.

@JordanMussi
Copy link
Contributor

@Sama34?

@Sama34
Copy link
Contributor Author

Sama34 commented Jul 13, 2014

I have been reading a little about the matter and I'm unsure whether we should make them public. That is why I'm waiting for some feedback. It is just three lines modifications so we can wait to the last day.

@DiogoParrinha
Copy link
Contributor

There's nothing wrong with having public attributes, we're not following any OOP standard so we do whatever we think is best for the plugin developers :)

@Sama34 Sama34 added the fixed label Jul 16, 2014
Sama34 pushed a commit that referenced this issue Jul 16, 2014
@Sama34
Copy link
Contributor Author

Sama34 commented Jul 16, 2014

This should be now finished.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled t:enhancement Type: Enhancement. Contains minor improvements
Projects
None yet
Development

No branches or pull requests

4 participants