Savageman

<?php

return [
    '-720,0' => [
        'code' => 'Etc/GMT+12',
        'name' => 'International Date Line West',
        'offset_minutes' => -720,
        'offset_hour' => '-12:00',
        'dst' => false,
    ],

Savageman

<?php

class Form extends \Fuel\Core\Form {
    
    public function field_template_public($build_field, \Fuel\Core\Fieldset_Field $field, $required) {
        return parent::field_template($build_field, $field, $required);
    }
    
    public function build_field($field) {
        

Savageman

<?php

namespace Cms;

class Widget_Password extends \Fieldset_Field {
    
    /**
     * @var \Cms\Fieldset_Field
     */
    protected $password;

Savageman

<?php

class Fieldset extends \Fuel\Core\Fieldset {
    
    /**
     *
     * @param   \Fuel\Core\Fieldset_Field  $field  A field instance
     * @return  \Fuel\Core\Fieldset_Field 
     */
    public function add_field(\Fuel\Core\Fieldset_Field $field) {

Savageman

Incorrect ES5 fallbacks

Over the weekend I implemented a few Array methods in plain JavaScript to avoid recently patched Rhino bugs. That got my thinking about ES5 fallback implementations in various JavaScript libs/frameworks/transpilers. I decided to compile a not-so-complete list of ES5 related discrepancies found in many of them. Differences in native vs. fallback implementations create cross-browser inconsistencies and increase the chance of usage errors. I hope this post will raise awareness of just how hard it is to follow spec (during my research I found a few issues in my own projects too). All library developers should to take a closer look at their code and make the small changes needed to follow the specification (especially if your code forks for native methods).

Common Issues

Most implementations suffer from the following