Comments (3)
I see where you are coming from, but that might be a bit too "abstracted". The base implementation with overridable functions is probably the best approach for readability and simplicity.
A change like this would also be API breaking.
from chatgpt-java-api.
As you pointed out, there will probably be increased number of OpenAI "implmentations". For example OpenAIV2, OpenAIV3, AzureOpenV2 etc... How are we supposed to work with these classes? Use them directly? That's not why OOP was invented.
As stated in SOLID principles by Robert C. Martin:
Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. This means that objects of derived classes should be able to replace objects of the base class without affecting the correctness of the program. => OpenAI is NOT a base type for AzureOpenAI, because it works internally differently. If we had an abstracted OpenAI type, that would be different, of course.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. This principle promotes the use of interfaces and abstract classes to decouple components and create flexible systems. => this is exactly what frameworks like Spring adhere to and why they are so successful. By not providing an interface, we directly go against Spring's philosophy and making it hard to use in such frameworks (btw I already faced such issue in my project with this library).
btw without providing a really abstract interface, you are making the library harder to extend and therefore less likely to be used. Because other developers have no way of "interfacing" with the functionality of this library.
In few months there will be a lot of new classes and no programmer will be able to understand which should be used when unless they read the documentation and the code. That is a bad library in action, in my personal opinion.
from chatgpt-java-api.
I don't believe there will be OpenAI v2, but a v2/whisper
endpoint seems possible (maybe likely?). In this case, we wouldn't be reimplementing an entirely new OpenAI class, instead creating a new method to interact with that 1 endpoint.
But for devils advocate, let's assume OpenAI put the v1
endpoint so that they can rerelease the company under v2 with completely different endpoints and functionality. In this case, trying to add these methods into an interface breaks existing programs. Instead, a default implementation (OpenAI) or a completely separate class is best.
OpenAI being the base class, in context of both LSP and DIP makes sense. I agree with you 100% that Azure/OpenAI work internally different. I look at it as if java collections had the LinkedList extends ArrayList
... how horrible that would be! But also consider that we do not interact with the internals of AzureOpenAI or OpenAI. We interact with their API which is more or less the same. So if you look at it as the AzureOpenAI endpoints extending the OpenAI endpoints, both LSP and DIP are followed.
btw without providing a really abstract interface, you are making the library harder to extend and therefore less likely to be used. Because other developers have no way of "interfacing" with the functionality of this library.
I'm with you here. I am used to explicitly marking methods as final in java, and I don't often think about how in kotlin. Users should be able to override these API methods if they wanted to add custom logic. I definitely should mark most of these methods as open.
Just to sound professional I'll cite my favorite CS principle, DRY. Having OpenAI
as the base type allows default implementations for the methods and helps repeating code between OpenAI
and AzureOpenAI
.
btw I already faced such issue in my project with this library
I'm not exactly sure which issue you have faced... more context might be needed to justify changes.
from chatgpt-java-api.
Related Issues (20)
- Image Creation/Edits/Variations
- AzureOpenAI builder class HOT 1
- Exponential Backoff HOT 1
- Fix JavaTestAzure HOT 1
- Error “Could not find /.env on the classpath”. HOT 2
- EOFException and MalformedJsonException HOT 3
- functions HOT 1
- How to cancel request ? HOT 4
- Allow user to capture error message from OpenAI API if rate limit exceed HOT 2
- Assistants, Threads, and Runs
- Files inconsistancy
- Add Model Enum
- Add GitHub issue templates
- Add function parameter support for complex objects HOT 1
- Completions inconsistency
- Add january 25th models to `Model` constants
- Moderations Endpoint
- Streaming for assistants HOT 3
- Support for Vision API HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chatgpt-java-api.