Unknown component property | Accept with warning
大多数人认为设计系统应该严格限制和验证所有属性,以确保一致性和可预测性。但作者认为应该接受未知组件属性,但仅发出警告。这种方法挑战了传统设计系统必须严格控制所有方面的观念,提供了一种更为灵活的方法,允许创新和扩展,同时仍保持基本的结构和约束。
Unknown component property | Accept with warning
大多数人认为设计系统应该严格限制和验证所有属性,以确保一致性和可预测性。但作者认为应该接受未知组件属性,但仅发出警告。这种方法挑战了传统设计系统必须严格控制所有方面的观念,提供了一种更为灵活的方法,允许创新和扩展,同时仍保持基本的结构和约束。
ADeLe is designed to evolve alongside advances in AI and can be extended to multimodal and embodied AI systems.
这一前瞻性声明展示了ADeLe框架的灵活性和扩展性,令人惊讶的是它能够适应AI技术的快速发展。这表明ADeLe不仅是一个静态评估工具,而是一个动态评估框架,能够随着AI系统的演进而不断更新,为未来更复杂的AI系统(如多模态和具身AI)提供了评估基础。
I think the fact that it's so simple to add, makes the case to just keep it in userland.
You can require plugins for Filewatcher, which extends core functionality.
extensible plugin system.
Practically speaking, if you can't think of a reason why it would be dangerous then theres more to be gained by opting for extensibility.
Marking methods protected by default is a mitigation for one of the major issues in modern SW development: failure of imagination.
If it's dangerous, note it in the class/method Javadocs, don't just blindly slam the door shut.
When a developer chooses to extend a class and override a method, they are consciously saying "I know what I'm doing." and for the sake of productivity that should be enough. period.
Been disappointed, surprised or hurt by a library etc. that was overly permissive in it's extensibility? I have not.
grammar Parser { rule TOP { I <love> <lang> } token love { '♥' | love } token lang { < Raku Perl Rust Go Python Ruby > } } say Parser.parse: 'I ♥ Raku'; # OUTPUT: 「I ♥ Raku」 love => 「♥」 lang => 「Raku」 say Parser.parse: 'I love Perl'; # OUTPUT: 「I love Perl」 love => 「love」 lang => 「Perl」
Definable grammars for pattern matching and generalized string processing
annotation meta: may need new tag: "definable __"?
Yes, using custom tags. Example in Python, making the !join tag join strings in an array:
(you can get pretty far with <svelte:component> and passing component constructors around and spicing up props along the way)
I have a rule that I won't allow Capybara to be monkey-patched in Poltergeist. This gives some indication to users about whether something is non-standard. So basically all non-standard stuff must be on page.driver rather than page (or a node).
The protocol is intended to be extensible; future versions will likely introduce additional concepts such as multiplexing.
add_class Set do |value, options| Set.new self.Array(value, options || {}) end use :NUMBER_SET, class: Set, of: Integer
it focuses on compiling non-standard language extensions: JSX, TypeScript, and Flow. Because of this smaller scope, Sucrase can get away with an architecture that is much more performant but less extensible
Ok, I have seen that there are lot of built-in and third party validations, but sooner or later I will face a validation rule not covered by this buffet. Can I build a custom one? Of course you can!
It is easily extensible (already implemented Final Form and Formik plugin extensions).
I'm okay with an overall design that allows people to plugin the parts they need in order to be able to generically support a compile-to-javascript language, but to bake in support for one singular solution because its popular is simply bad engineering.
"Software entities ... should be open for extension, but closed for modification."
I don't understand the need for the name "Open–closed principle". It doesn't seem meaningful or clear to me.
Can't we just call it "extensibility" or "easily extendable"? Doesn't "extensibility" already imply that we are extending it (adding new code on top of it, to interoperate with it) rather than modifying its source code?
such an entity can allow its behaviour to be extended without modifying its source code.
In these two languages, the "Function is a first-class citizen, which allows for aggregation of behaviors outside of the class.
open/closed principles
Allows registration of TypeScript custom transformers at any of the supported stages:
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.
Does it look like a decorator plugin in Ractive, right
Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.
For several reasons the Simple backend shipped with Active Support only does the "simplest thing that could possibly work" for Ruby on Rails3 ... which means that it is only guaranteed to work for English and, as a side effect, languages that are very similar to English. Also, the simple backend is only capable of reading translations but cannot dynamically store them to any format.That does not mean you're stuck with these limitations, though. The Ruby I18n gem makes it very easy to exchange the Simple backend implementation with something else that fits better for your needs, by passing a backend instance to the I18n.backend= setter.
This is where the incredibly useful gettext filter comes in. If you take a peek at your plugin's code you'll see strings like this: .gist table { margin-bottom: 0; } <?php _e( 'Related Products', 'woocommerce' ); ?> view raw sample-translatable-string.php hosted with by GitHub You can easily translate these strings by adding a filter to your functions.php file: .gist table { margin-bottom: 0; } <?php /** * Change text strings * * @link http://codex.wordpress.org/Plugin_API/Filter_Reference/gettext */ function my_text_strings( $translated_text, $text, $domain ) { switch ( $translated_text ) { case 'Related Products' : $translated_text = __( 'Check out these related products', 'woocommerce' ); break; } return $translated_text; } add_filter( 'gettext', 'my_text_strings', 20, 3 );
This seems like a pretty good way to handle adding add-ons.
See also: https://github.com/sanpii/effitask
You might want developers building projects with this CMS to be able to change the behaviour of some UIs, or to be able to provide new components that can be consumed by the CMS. Those components can't easily be included in the JS bundle for the CMS, as it would require recompiling the shipped code with outside references.
Registering new services to the Injector If you've created a module using React, it's a good idea to afford other developers an API to enhance those components, forms, and state. To do that, simply register them with Injector.
Super flexible & extensible SilverStripe fits the outcomes you want, and doesn't force your business outcomes into an out-of-the-box solution. Customise to your needs!
Onivim 2 leverages the VSCode Extension Host process in its entirety - meaning, eventually, complete support for VSCode extensions and configuration.
The chosen approach pushes a lot of complexity out of the core. As a result it might take more code to achieve certain functionalities. This is the price of flexibility. And that's the primary design goal of Reactabular.
Reactabular has been designed to be extensible. Rather than implementing a lot of functionality in its core, it provides extension points. You can, for instance, customize rendering on cell level. It is possible to implement functionality, such as search, pagination, sorting, and inline editing, through composition.
But how could it be made more extensible?